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CAPACITY ALLOCATION SYSTEM USING 
SEMI-AUTONOMOUS NETWORK ELEMENTS TO 
IMPLEMENT AND CONTROL A TRANSMISSION SCHEDULE 

FIELD OF THE INVENTION 

This invention relates to communication methods and apparatus for providing network 
management, bandwidth and path control in a heterogeneous network that may be composed 
of multiple vendor equipment and transmission paths. More specifically, the communication 
5 system concerns semi-autonomous implementation components within a management 
hierarchy to globally manage multiple vendor elements while satisfying local network 
demands. 

BACKGROUND OF THE INVENTION 

Telecommunications services have, for many years, attempted to optimize or 
10 minimize bandwidth usage between network elements. Since the modern communications 
era, brought about by the theories of Shannon, telecommunications engineers have been 
keenly aware of the need to provide optimal, or at least good solutions, to bandwidth 
allocation problems in point-to-point and point-to-multipoint networks. 

In wireless communication systems, solutions to bandwidth allocation problems can 
15 be seen in the way data is modulated to "share" finite resources. For example, time division 
multiple access ("TDMA") provides a means for multiple stations to access time slots on 
satellite carriers and thereby "share" bandwidth resources. Code Division Multiple Access 
("CDMA") provides a means to use code division modulation techniques (time and frequency 
modulation) for multiple point access to a predetermined range of bandwidth and thereby 
20 "share" bandwidth space. Likewise, frequency division multi-access ("FDMA") provides a 
means to divide up and share a finite bandwidth resource. 
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More elaborate schemes to dedicate bandwidth in accordance with a predetermined 
transmission schedule and modulation plan can be seen in U.S. Patent No. 5,592,470 to 
Rudrapatna et aL 9 ("Rudrapatna") issued January 7, 1997, (the "Rudrapatna patent"). The 
Rudrapatna patent concerns a terrestrial micro-port network that allocates bandwidth to 
5 terrestrial micro-port receivers based on a pre-determined schedule and modulation plan. The 
pre-determined schedule and plan may be subsequently modified by dynamic demands on the 
micro-ports. The network can then satisfy the dynamic demands by moving channels 
between modulation and polarity schemes in pre-determined amounts. 

In wireless networks, certain communications links require more bandwidth and 

10 power resources than others. This is necessary to maintain specified information throughput, 
to provide appropriate grades of service or due to varying site configurations (e.g., different 
antenna sizes). Whenever a change in network resource allocations is required to match 
varying traffic requirements, a new transmission plan may or may not be implemented. This 
may necessitate programming, transmitting and receiving communications equipment, e.g., 

15 amplifiers, modulators and demodulators, to support the new resource assignments. These 
and other problems in bandwidth allocation in a multi-vendor network are addressed by the 
present invention. 

SUMMARY OF THE INVENTION 

The methods and apparatus disclosed herein may assign and re-assign available 
20 transmission resources in point-to-point, multipoint and broadcast wireless networks. This 
may be accomplished on the basis of information capacity and connectivity requirements 
between transmitters and receivers of communications links at the time of assignment or re- 
assignment. The system may also provide a network administrator with novel tools and 
automated methods to define and implement network transmission plans and to modify 
25 allocation decisions as traffic requirements change. 

-2- 
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The system may provide the tools to efficiently allocate transmission resources. These 
tools help implement the communications links that form wireless networks. An optimum 
resource or a "good fit" allocation is achieved when network users have just enough 
information transmission capacity to perform their tasks. One way to accomplish optimal or 
5 good transmission resource allocations in a wireless network is to analyze network users 9 
usage patterns and allocate capacity according to a time- varying schedule. 

By analyzing network usage patterns, a management component can determine a 
transmission plan schedule that efficiently allocates the satellite bandwidth available to the 
network based on historical usage patterns. The management component may automatically 
10 schedule and implement a transmission plan. As the network users' requirements change, the 
management component may update or modify the scheduled transmission plans to satisfy the 
new requirements. 

The system may automate implementation of transmission plans by reprogramming 
the system when predetermined parameters are reached. For example, the management 

15 component may determine a transmission plan from a historical analysis of bandwidth 
requirements between stations. This transmission plan may be automatically deployed to the 
network. The management component can then monitor and analyze network allocation 
demands to determine a new transmission plan. The new transmission plan can then be 
automatically deployed in the network when predetermined parameters are reached, such as, 

20 average change in bandwidth, e.g.^ bandwidth in use/bandwidth in the transmission plan, 
exceeds a predetermined amount or if a predetermined amount of time has transpired. The 
transmission plans may be propagated as generic network commands and translated into 
corresponding equipment parameters and associated control commands as required for 
reconfiguring network equipment elements. Thus, the system may generate and distribute 
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equipment configurations to network elements to reprogram for synchronized execution at 
predetermined times. 

The system further controls and schedules bandwidth between network elements to 
consider other network factors such as economic constraints. In a wireless communications 
5 network, each communications carrier should have just enough bandwidth and power 
necessary to meet the needs of its corresponding users. Although optimum resource 
allocation is the primary goal, sub-optimum allocation may be tolerated when economic 
constraints may limit transmission resources to finite amounts. Thus, for example, a dynamic 
bandwidth requirement at a network station may require an increase in bandwidth allocation 
10 from the station, such as when the queuing depth reaches a predetermined amount at the 
station switch. The station may have additional capacity available on an available 
communication link, however, the incremental capacity of the link may far exceed the 
bandwidth required to reduce the depth of the communication queue. Furthermore, the 
financial cost of the incremental capacity may exceed the cost of waiting for network usage to 
15 decrease to reduce the depth of the queue. The system, in this case, would allow the network 
to back up and flow control the user data before the system would allocate additional 
capacity. The system provides methods to use finite transmission resources by enabling 
power and bandwidth to be re-allocated as needed to meet changing communications 
requirements in satellite networks. However, the capabilities of the system are applicable to 
20 all wireless networks that can be modeled as a collection of transmitters, transmission 
resources, and receivers. 

The system provides a means to manage heterogeneous or multiple vendor network 
equipment over heterogeneous or multiple vendor transmission resources with multiple 
transmission paths. One such path may be via programmable C-, Ku-, or Ka- band satellite 
25 networks. Other paths may be via discrete carriers available on a preprogrammed networks 
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such as the Inmarsat, Globalstar or Iridium satellite systems. Yet other paths may be via third 
party medium or broadband networks such as the envisioned Teledesic satellite network. Yet 
another path may be over a programmable or managed network such as the Intelsat global 
satellite system. Thus, the system provides a means to define and manage capacity between 
5 network elements where the network may be a combination of a discrete bandwidth allocation 
network managed by an external system, a semi-programmable medium or broadband 
network wherein a varying amount of bandwidth may be allocated from an externally 
managed resource and a fully-programmable network where the resource is managed by a 
network management component. Thus, the management system provides a nearly 

1 0 transparent means by which an operator, user or network element may place demands on the 
network and the management system may satisfy those demands based on a least cost 
algorithm, quality of service parameters and pre-defined or time- varying transmission plans. 

The management system described may configure the transmission elements 
(transmitters and receivers) in a wireless network to implement a specified allocation of £ 

15 transmission resources according to varying, scheduled or ad-hoc capacity requirements. The ji l 
system maintains a schedule of transmission plan implementations and may automatically 
perform each implementation at a scheduled time. 

The semi-autonomous network management system essentially consists of two semi- 
autonomous components. The first component is the Implementation Component (IC) which 

20 executes at a site containing network transmission elements and the second is a Management 
Component (MC) which executes at a network management site. These components may be 
connected via a user datagram Internet protocol messaging format. 

At the heart of the system is the IC. The IC may be a stand-alone application program 
that controls one or more network elements. A network element may be the station or 

25 communication equipment physically controlled by an IC. Thus, it is usually the case that the 
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network element is a stationary or mobile communications node at a single physical location. 

The IC may, however, remotely control a network element. 

In one embodiment of the present invention, the IC application may execute in a 

dedicated processing environment such as a PC executing UNIX or other suitable operating 
5 system such as Windows or DOS. The IC may also execute on an integrated or embedded 

processor such as a PC on a card environment with an application specific or real time 

operating system executing thereon . 

The IC is semi-autonomous, e.g., it can translate allocation commands from a 

management component into executable commands for its associated network elements 
10 without having direct, full-time contact with the network management component. The IC 

may store pre-programmed parameters, transmission plans, or collection commands for 

automatic execution. The IC may map a network programming language command set or 

generic allocation command to a vendor specific command sequence. The IC may contact the 

management component to receive permission to access network bandwidth, to report the 
15 unavailability of network elements, or to request different allocation parameters if or when 

local demands exceed the IC's preprogrammed allocations. Thus, the^ IC may provide 

independent control over network elements while maintaining or executing a management 

plan. 

In the semi-autonomous network management scheme disclosed, transmission 
20 schedules may be loaded in advance of the implementation of the scheduled transmission 
plans. Then, at a predetermined time, the network can switch over to the new transmission 
plan to implement the optimal, or at least good solution, before more complicated dynamic 
bandwidth allocation algorithms would need to be employed. 

In addition to automatically implementing scheduled transmission plans generated by 
25 the management component, the system may also perform network usage analysis. 

-6- 
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Automated network usage analysis may require that the management component have access 
to traffic data collected for the network. The data may be collected automatically or manually 
by the management component or the implementation component may interact with the 
elements in the network to collect the usage data. The management component may use 
5 statistical methods to analyze the gathered network usage data to suggest or implement 
optimize transmission plans for efficient use of the available resources according to a 
schedule. 

Efficient use of bandwidth spectrum may be achieved on various levels in the system. 
On a first level, bandwidth may be scheduled in accordance with a historical analysis of 

10 demands on the network. For example, it may be determined that Monday morning traffic is 
mostly outbound {i.e., from a central earth station to a mobile station). On Fridays, however, 
most of the traffic is in the opposite direction (i.e., from mobile stations back to the central 
earth station). In this instance, an assymetric channel may be opened for Monday traffic to 
provide higher outbound data and a slower speed return path. Then the opposite allocation 

15 may be established for Friday's traffic (e.g., a high speed channel from a mobile station to the 
central station and a low speed acknowledgment channel from the central station back to the 
mobile station). This may provide an optimal, or at least a cost-effective solution for the 
capacity requirements at a particular time. 

On a second level, the system may allocate capacity based on class of service 

20 parameters available, for example, through an Asynchronous Transfer Mode ("ATM") type 
packet format. For example, a class of service may identify data packets with tow priority for 
a particular application. In such a case, an expensive satellite carrier may not be necessary 
and a lower-cost transmission resource may be put online by the network to pass the required 
data packets. Thus, the present network can mix class of service bandwidth allocation 
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methods with least cost routing decisions based on predetermined parameters programmed in 
the IC. 

The semi-autonomous nature of the network management components may use a 
datagram protocol for interprocess communication. More specifically, the network 
5 components may communicate through the use of the User Datagram Protocol ("UDP") over 
an internet protocol ("IP"). Communication between the management component and the IC 
may use a polled or interrupt methodology. 

In a polled mode, the management component contacts each of the ICs to pass 
UDP/IP messages or to receive Transmission Control Protocol/Internet Protocol ("TCP/IP") 

10 information from the particular IC. In an interrupt driven mode, the IC may attempt to 
communicate with the management component. The interrupt mode may be used to re- 
establish contact with the MC if the IC loses synchronization with the network or to pass 
alarm or other local conditions happening at the IC that may not be detected by the 
management component. In the interrupt driven mode, the IC may have a preassigned back- 

15 up channel or predetermined bandwidth allocation to communicate with the management 
component. The management component may be programmed to look for alarm conditions 
or communication attempts from the ICs when predetermined parameter thresholds are 
reached. 

Additionally, a signaling control mechanism between the management component and 
20 the ICs is disclosed. The signaling control mechanize operates to ensure that each of the ICs 
receives the appropriate message(s) and that the transmission plan may be implemented 
according to the predetermined schedule. 

The signaling control mechanism between management component and 
implementation components may communicate by exchanging the following UDP/IP 
25 messages. 
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Transmission Control Order 
Abort Order 

Acknowledgment of a Transmission Control or Abort Order 
Audit Request 
Audit Response 

A transmission control order ("TCO") specifies new transmission parameters for a 
transmitter or receiver. The TCO may also specify the implementation time. The 
implementation time may be the time at which elements should begin using the transmission 
10 parameters specified in the order. TCOs are generated by the system to implement a new 
transmission plan. The system sends TCOs to the ICs of transmitters and receivers that must 
change parameters to implement the new transmission plan. TCOs may be stored on a hard 
drive or other non-volatile storage so that they are preserved through IC restarts and at IC 
power failures. 

15 It is possible that an IC may be down or may not be able to communicate with the 

managed equipment at the execution time of a TCO. When this happens, the IC may 
implement the current transmission plan or may implement a default state when the IC 
reestablishes communication with the managed equipment. 

The IC may send an acknowledgment of a TCO when a- TCO is received from the 
20 system. If any of the requested parameter changes cannot be implemented because the 
managed equipment or the configuration files do not support it, the IC notifies the 
management component of this in the acknowledgment. 

The IC may also check that the parameter values are valid for the managed network 
equipment. Parameter ranges are specified in the Equipment Controller configuration files in 
25 the IC, discussed further below. 

A confirmation message may not be necessary for reporting the successful 
implementation of a transmission control order. Because the majority of satellite networks 
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implement single links to each remote site, if an IC is not able to implement a TCO, the IP 
connection to the system may be lost. The system management component may detect the 
problem from the lack of audit responses. If the system does not receive an audit response 
from an IC, the system may update the site status and alerts the management component 
alarm. 

An abort order may instruct the IC to cancel any pending TCO for the specified 
transmitter or receiver. The system may send abort orders when a pending implementation is 
canceled by the Administrator. The IC may send an acknowledgment when it receives an 
abort order. The IC may send an acknowledgment when it receives a TCO or abort order 
from the management component. 

An audit request may be periodically sent to an IC by the management component 
The management component may send an audit request to check the status of a transmitter or 
receiver. One audit request may be sent for each transmitter and receiver being managed by 
anIC. 

An audit response may be sent by an IC when an audit request is received from the 
management component. The audit response may contain the current parameter values for 
the transmitter or receiver specified in the audit request. 

An audit response may be similar in structure to a TCO. It may include the hardware 
identification for a transmitter or receiver and a list of model parameters and their current 
values as reported by the physical hardware. 

The receive frequency model parameter may be a special case: the frequency reported 
by the demodulator may not match the commanded receive frequency. Sources of frequency 
error throughout a wireless carrier transmission process may result in an offset between the 
expected and actual receive frequencies. Many demodulators are designed to accommodate 
this frequency offset by searching for the transmitted carrier in a neighborhood around the 
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commanded receive frequency. However, the system may also account for this receive 
frequency offset when determining whether the physical hardware is using the same 
parameters as in the most recently implemented TCO. 

The management component may periodically request the current parameters from all 
5 transmitters and receivers. This network auditing function may perform the following 
functions: 

• Maintains the status of communications between the management component and 
the transmitters and receivers in the network. 

• Detects parameter changes of the managed equipment. 

10 

When a difference between the specified transmission parameters for a transmitter or 
receiver and the managed equipment is detected, the management component may notify a 
Bandwidth Administrator. The management component operator interface may use an 
audible as well as visual alert to improve the chance that a Bandwidth Administrator will 

1 5 notice the difference and act to resolve it. 

Fig* 21 shows equipment controller IC (150). IC (150) may have a configuration 
database (152) which stores a configuration mapping for end-user receiver and transmitter 
equipment which is interfaced by, for example, serial devices (164, 166, 172, 174) and 
parallel devices (188, 190). The receiver/transmitter equipment may be from multiple 

20 vendors and thus the configuration database (152) maps commands from the management 
component (156) to a particular device. This feature of the IC may allow the use of a generic 
network control language in commands sent to IC (150) (discussed further below). 

The system is designed to manage all transmission equipment, regardless of 
manufacturer. To achieve this, the management component deals with model satellite 

25 transmitters and receivers as illustrated in Figure 6. 
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The transmitter and receiver models have the parameters necessary to implement a 
wireless link. Only parameters that relate to the establishment of a wireless link need be 
included in the transmitter and receiver models. 

The management component may not require information about the physical 
equipment elements used to implement the communications links in the managed network. 
Therefore, the MC need not map the model parameters directly to commands for the physical 
hardware of the transmitters and receivers at a site. The IC may have information about the 
physical hardware at its site and may map the model parameters to the appropriate commands 
and responses. 

The IC may read information about the physical hardware from the configuration files. 
These files may specify the information required by the IC to monitor and control the 
managed equipment at a site. The IC configuration files may contain the information 
necessary to convert parameter changes for the model transmitters and receivers into 
commands to the physical hardware. 
BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a pictorial schematic of a star topology satellite network showing a shared 
outbound simplex channel and a private inbound simplex channel. 

Fig. 2 is a pictorial schematic of a mesh topology for a satellite network showing 
shared outbound simplex channels. 

Fig. 3 is a functional schematic of a transmission equipment model depicting 
modulators, up converters, and the loss and gain elements in the circuit, the site antenna, and 
the corresponding receiving circuits showing gain and loss elements, the down converter, and 
the demodulator. 

Fig. 4 depicts software components for the semi-autonomous network management 
system of the present invention. 

- 12- 
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Fig. 5 is a functional schematic detailing the software components. At the control site 
there is a management (control) component, a display controller and an event logger 
component. At the remote site, there is the IC, the equipment controller component and a 
display controller and event logger component. The management transmission and receiver 
5 equipment is further shown as being controlled from the IC equipment control. 

Fig. 6 is a functional schematic showing the elements of a transmission model that are 
controlled by the semi-autonomous ICs of the present invention. 

Fig. 7 shows a further functional schematic of the IC systems. 

Fig. 8 is a functional schematic showing the software process architecture of the semi- 
10 autonomous network management component. 

Fig. 9 is a functional schematic of the information flow in the semi-autonomous 
components of the present invention. 

Fig. 10 is a graphical depiction of the transmission plan allocation of available . 
spectrum. 

15 Fig. 11 is a graphical depiction of the transmission plans of a transmission pUurr. 

schedule. 

Fig. 12 is a graphical depiction of a transmission plan schedule implemented 
throughout a particular day. 

Fig. 13 is a flowchart illustrating a method of transmission plan deployment and 
20 execution. 

Fig. 14 is a flowchart illustrating a method of executing a bandwidth allocation 
request. 

Fig. 15 is a graphical depiction of a UDP datagram format employed in the 
management components. 
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Fig. 16 is a functional schematic of the request/command flow direction of the present 
invention. 

Fig. 17 is a flowchart illustrating a method of grading, employing, and implementing 
transmission plans within the network. 

Fig. 18 is a graphical depiction of how the methodology of the present invention 
views transmission media as resources. 

Fig. 19 is a graphical representation of the methodology of the present invention 
allocating transmission media resources. 

Fig. 20 is a graphical depiction of a timing transmission plan implementation. 
Fig. 21 is a graphical depiction of the command processing flow in the equipment 
controller. 

Fig. 22 is a graphical depiction of the process flow for network audit processing. 

Fig. 23 is a graphical depiction of the auto command flow with respect to timing. 
DETAILED DESCR IPTION OF PREFERRED EMBODIMENT 
1 5 The system is composed of two software components, the Management Component 

("MC") and the Implementation Component ("IC") that work together to monitor and control 
the transmission elements in a wireless network. 

The MC includes an operator interface for configuring, monitoring, and controlling 
the capacity allocation activity in a wireless network. It may be a Win32 application that runs 
20 on a Windows NT workstation which may be located at a network operations center (NOC). 
Configuration, monitoring, and control of the capacity allocation may be accomplished with 
the management component. The MC communicates with the other software component, the 
IC, using the Internet Protocol (IP) family of network protocols as illustrated in Figures 4 and 
5. 
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The IC is the application that may communicate with the physical hardware elements 
implementing the communications links in a wireless network. The IC may be a Win32 
application that runs on a computer located at each site in the network. The IC may read a set 
of configuration files that describe the network equipment to be monitored and controlled. 
5 These configuration files may be text files and may be created and modified with a text editor 
program. In general, the configuration files are re-usable, that is the same configuration file 
may be used at multiple sites if the same network equipment is used at both sites. 

As discussed above, the MCs and ICs communicate by exchanging IP messages. 
Figure 5 is a representation of the connectivity between the management component and the 

10 IC in a wireless network. The IP connections may be implemented on the satellite network, 
through the Internet, or through a private network. A second physical communication path 
between the MC and the ICs may be used to establish IP communications. Typically, ICs do 
not communicate with other ICs; however, communication links may be established between 
components to further communication with the MC. 

15 The management system is designed around several elements. These are the '-y 

Transmission resource 
Site 

Transmitter 
Receiver 

20 • Transmission element 

Transmission plan 
Implementation 
Schedule 
Execution time 



25 



A transmission resource may be a portion of a wireless capacity (power and bandwidth) that 
may be used by the transmitters in a network. A site may be a collection of transmitters and 
receivers controlled by a single IC. Normally one IC controls all of the transmitters and 
receivers at a network site. However, the transmitters and receivers at a network site may be 
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controlled by more than one IC. For example, this may occur at a hub site in a satellite 
network with a star configuration. 

A transmitter is an equipment element that modulates an information signal so that it 
may access a wireless media. A receiver is an equipment element that demodulates a signal 
received from a wireless media to recover the information from the broadcast signal. A 
transmission element may be a transmitter or receiver in the network configuration. Although 
transmitters and receivers may be different and perform different functions, the management 
component may perform some operations in which transmitters and receivers are both treated 
the same way. For example, the MC may audit the status of all transmitters and receivers in 
the network. The management component may not distinguish between transmitters and 
receivers when performing this auditing operation. 

A wireless link may be created when an information signal is modulated by a 
transmitter and then demodulated by one or more receivers. A wireless communication 
network is a collection of communications links that enable information transfer among the 
sites in the network. Each link requires some of the transmission resources available to the 
wireless network. The allocation of the available transmission resources among the 
transmitters in a network is a transmission plan. These transmission plans may define the 
information capacity and connectivity requirements between the transmitters and receivers in 
the network. 

Only transmitters may need to be specified in a transmission plan. Transmitters 
generate the signals that use transmission resources. The number of receivers demodulating a 
wireless signal does not affect the amount of transmission resources (bandwidth and power) 
used to implement the link. 

Implementation may be the process of configuring the transmitters and receivers in a 
wireless network to allocate the transmission resources as specified in a transmission plan. 
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The management component may implement a transmission plan by sending orders to the ICs 
controlling the transmitters in the transmission plan and the receivers listening to those 
transmitters. These orders may specify the transmission parameters for the transmitters and 
receivers and when they should be implemented. The IC may send the equipment-specific 
5 commands that implement the transmission parameters at the specified time. The 

implementation schedule may be a list of all transmission plan implementations that may 
automatically be executed in the future. The schedule may be maintained by the MC 
application. An operator may add implementations to the schedule, remove implementations 
from the schedule, and move existing implementations to different times. An execution time 

10 consists of a transmission plan and the time at which the transmission will be implemented. 
The time may be a recurring time, for example 1 200 UTC every day or 0600 UTC every 
Monday. The implementation schedule may be built from execution times. 

The information architecture of the system applies primarily to the structure of the 
database maintained by the Management Component and may define the structure of the v 

15 messages exchanged between the management component and ICs. 

The information maintained by the management component (network configurations, 
transmission resource configurations, transmission plans, etc.) may be stored in a relational 
database. 

The management component may require information about the wireless networks 
20 that it manages. A network may be viewed as being composed of sites, transmitters, and 
receivers. Information about these objects, e.g., sites, transmitters and receivers, and the 
relationships among them may constitute a network configuration. A network may be a 
collection of sites that are linked by transmission resources. The following information may 
be specified for each network managed by the system: 
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□ Name 

□ Transmission resources available for use by the network 

5 The system may maintain the following information for each network: 

□ Network ID 

□ Status 

□ Sites in the network 

1 0 A site may be the physical location of an antenna in a wireless network. In addition to 

an antenna, a site may have at least one transmitter or receiver. The system may require that 
the following information be provided for each site: 

□ Name 

□ NMS IP address 

15 □ Location (street address, geographic coordinates, etc.) 

□ Contact information (telephone numbers, operators' names, radio frequencies, etc.) 

□ Antenna parameters (size, gain, etc.) 

The system may maintain the following information for each site: 

20 □ Site ID 

□ Status 

□ Network to which the site belongs 

□ Transmitters at the site 

□ Receivers at the site 

25 □ Time of last management component transmission to site 

□ Time of last IC response from site 

In the system, a transmitter may comprise the equipment necessary to convert a digital data 
stream into a carrier for transmission over a wireless resource. The system may require that 
30 each transmitter be uniquely named. The system may maintain the following information for 
each transmitter: 

□ Transmitter ID 

□ Status (UP, DOWN, FIXED, UNKNOWN) 

□ Site where the transmitter is located 

35 □ Receivers that should be receiving the transmitter's carrier(s) 
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The system may track the status of the transmitters in a wireless network. Possible 

status values for the tracked components may be: 

UP the transmitter is currently generating a carrier and is under the control of 

5 the management component 

DOWN the transmitter is not generating a carrier but is under the control of the 
management component 

10 FIXED the transmitter is generating a carrier and the management component 

knows the characteristics of the carrier but the transmitter is not under 
management component control 

UNKNOWN the management component does not know if the transmitter is 
1 5 generating a carrier 

In the system, a receiver may comprise the equipment necessary to receive a carrier 
transmitted over a wireless resource and recover the digital data stream. The following 
information may be specified for each receiver: 

20 □ Name 

□ Transmitter of the carrier the receiver should receive 

The system may maintain the following information for each receiver: 

□ Receiver ED 
25 □ Status 

□ Site where the receiver is located 

A pool may be a collection of transmission resources available for use by the managed 
networks. Each transmission resource is a portion of transmission capacity (power and 
30 bandwidth). The following information may be required for each pool: 
□ Name 

a Transmission resources in the pool 
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The system may maintain the following information about each pool: 

□ Pool ID 

□ Networks using the pool 

A transmission resource may be a portion of transmission capacity (power and 
bandwidth). The system may require the following information about each transmission 
resource: 

□ Description (transponder, provider, etc.) 

□ * Start frequency 

□ End frequency 

□ Translation offset 

□ Power allocation 

□ Cost metrics 

The system may maintain the following information about each transmission resource: 

□ Transmission resource ID 

□ Pool to which the Transmission resource belongs 

A transmission plan is an allocation of transmission resources to one or more carriers 
in a wireless network. The system may specify the following information about a 
transmission plan: 

□ Execution time 

□ Duration 

□ Comments 

The system may maintain the following information about a transmission plan: 

□ TP ID 

□ State (UNSCHEDULED, SCHEDULED, PENDING, READY, STARTING 
ACTIVE, COMPLETED, or CANCELLED) 

□ BARs satisfied by the TP 

The system may manage sites with multiple transmitters and receivers. Therefore the 
system maintains a naming scheme for identifying a specific transmitter or receiver at a site. 



-20- 

.9938274A1_I_> 



WO 99/38274 PCT/US99/01317 

Figure 9 may represents the flow of hardware identification information from the IC 
configuration files to the management component. The identification information may 
originate in the configuration files generated for a site in a network. The configuration files 
for a site may be read by the IC. 
5 Figure 9 shows the information flow in the system. Each transmitter and receiver at a 

site may be designated by an equipment class. Each member of a class is assigned an 
instance number. Together, the equipment class and instance identify a unique transmitter or 
receiver at a site. A Bandwidth Administrator (902) may supply the hardware identification 
when configuring the transmitters and receivers of a site for bandwidth management. The 

10 flow of information shown in figure 9 simplifies network configuration maintenance and 
reduces the risk of problems due to inconsistent configuration information in the network. 
The circles with a slash (914, 916) illustrate that neither the Bandwidth Administrator (902) 
nor the management component (906) require access to the configuration files (910). 

The system software components may exchange information by sending and receiving 

1 5 messages using network or external connections. The management process may 

communicate with all of the IC processes. Each IC communicates only with the management 
component. 

The User Datagram Protocol (UDP) of the Internet Protocol (IP) suite may be used to 
transport the inter-process messages. The system may use the combination of IP address and 
20 UDP port to identify the ICs in the network. Site identification information may not be 
required in the message if the IP address and port are already available in the IP and UDP 
headers. 

The management and ICs may communicate using several types of messages. 
Although each type of message contains different information and fulfills a different purpose, 
25 the message types share some common characteristics as shown in Figure 15. 
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□ A message is sent as a single UDP datagram 

□ Only ASCII characters are allowed in a message 

□ A message is a series of information fields 

□ Fields are terminated with an ASCII linefeed (LF) 

5 □ A message is terminated with an empty field (single LF) 

□ The first three fields are the same for any message (message type, sequence number, and 
hardware identification) 

Although system messages contain only ASCII characters, the messages may be compressed 
10 before delivery via UDP. Messages may then be uncompressed after receipt Fields #4 

through #N (1514, 1518) in figure 15 are information fields (1524). The fields prior to the 

information fields in a BMF message are header fields (1528). 

Header fields may be present in system messages (1528). Typically, the order and 

format of the header fields are the same, regardless of message type. The format of a header 
15 field is simple: a string terminated by an ASCII linefeed (LF) character (1 504, 1508 and 

1510). The string can contain any printable ASCII character except LF. The management 

and ICs may communicate using the following message types: 

□ Transmission Control Order (TCO) 

□ Abort Order (ABRT) 

20 □ Acknowledgment (ACK) 

□ Audit Request (AREQ) 

□ Audit Response (ARSP) 

The mnemonic in parentheses after each message type is the identifier used in the first 
25 field (1 502) of a system message (1 526). After the message type field, the next field in a 
system message is a sequence number (1506). The management component maintains a 
sequence number for each piece of managed equipment (e.g. receiver or transmitter) in a 
network. The IC may use the sequence number from a request message in the response 
message. 

30 Sequence numbers may be used to match responses (ACK or ARSP) with requests 

(TCO, ABRT, or AREQ). The use of sequence numbers (1506) prevents confusion when 
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multiple responses are received when multiple requests were sent due to message delivery 
delay or temporarily unavailable components. 

Figure 1 8 illustrates a transmission plan for allocating transmission media resources 
among transmitters in a network. Figure 18 shows that a transmission media can be divided 
5 up into discrete segments (10). A network management plan can view discrete segments (10) 
of bandwidth as discrete transmission media sources (12). A transmission plan (16) may be 
used to map a network transmitter (18) through a link (14) to a predefined transmission media 
resource (12). For example, transmission network transmitter (20), in particular transmitter 
(18), may be mapped through transmission plan (16) to two discrete segments (10) through 

10 link (14). The network media resource may be a star topology as shown in Fig. 1 or a mesh 
topology as shown in Fig. 2. 

Network transmission media resources may also be on separate networks. For 
example, a first network transmission rsource may be capacity from the INMARSAT satellite 
network or through private networks on a C, KU, KA or L-Band. The network transmission 

15 resources may be further augmented by low earth orbiting satellites, medium earth orbiting 
satellites or geosynchronous satellites. Low earth orbiting satellites may be represented by 
the Iridium system employed by Iridium, Inc., whose discrete bandwidth allocation 
methodology is herein incorporated by reference. Geosynchronous satellites may also 
provide additional transmission resources as represented by the Inmarsat or Intelsat satellite 

20 services whose bandwidth allocation methodologies are herein incorporated by reference. 

The management component or the ICs do not need to be in direct control of the 
bandwidth allocation to utilize transmission media sources. For example, bandwidth 
allocation on the Iridium satellite system may operated independently of the management 
component and the ICs. However, the bandwidth allocation methodologies of, for example, 

25 the Iridium network, may be employed to treat the resultant communication path as a 
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transmission media resource under control of the management component. Indeed, multiple 
carriers from a third-party system may be allocated in discrete predefined units, such as 
discrete segments (10), shown in Fig. 18, for utilization by the present invention as a media 
resource. 

Fig. 19 is a graphical depiction of network elements, ICs, a management component 
and a transmission plan. A central controller of the present invention may be represented by 
Management Component ("MC") (30). MC (30) is in communication with a plurality of ICs 
("ICs") (32, 34, 38, 40) through links (31). Each IC may represent a particular site that is 
under network management control by the MC. Each IC may have network equipment (42) 
under its control. For example, IC (40) has transmitter (44) under its control and BIC (38) 
has receivers (46, 48, 50, 51) and transmitters (56, 57) under its control. IC (36), however, 
has receiver (54) and transmitter (52) under its control. The present invention implements a 
transmission plan (43) through a mapping of network equipment (42) to transmission media 
resources (46). For example, transmitter (44) has been allocated transmission media resource 
(45) for reception by receiver (48) as indicated through up link and down link mappings in 
transmission plan (43). This may represent a combined transmission media resource whose 
overall capacity is the entire discrete amount allocated at transmission media resource (45). 
For example, a dynamic bandwidth requirement for a connection at a predefined class of 
service may be split into two discrete carriers. The discrete carriers may be represented by the 
two discrete media resources allocated at transmission media resource (45) to provide an 
overall throughput necessary to accommodate the predetermined capacity to support the class 
of service. The excess capacity may be used to provide the time recovered to reassemble the 
packets at receiver (48). This methodology is useful in the instance where, for example, a 
class of service from a particular end-user exceeds the network capacity to satisfy the demand 
on a single channel or contiguous media resource. For example, the class of service requires 

-24- 

9938274A1 J_> 



WO 99/38274 PCT/US99/01317 

a connection that exceeds the bit rate capacity of the modulator at a particular transmitter, but 
two modulators would supply ample bandwidth for the class of service. In that instance, the 
IC or the management component could divide a packet data stream from the end-user device 
onto the two different modulators. In that instance, multiple transmission media resources 
5 may be allocated to satisfy the overall class of service demand. 

A further representative example of a transmission plan employed herein is a 
broadcast from IC (38) through transmitter (56) which has been allocated transmission media 
resource (57). Transmission media resource (57) may be used for reception by both IC (34) 
and receiver (58) and IC (32) and receiver (60). This is an example of a point to multi-point 
10 broadcast. The point is represented by uplink transmitter (56) and the multi-points are 
represented by receivers (58) and (60). One representative application of such a plan is, for 
example, a broadcast message from transmitter (56) to two simultaneous sites represented by 
ICs (32) and (34). 

Another representative example of a transmission plan employed herein is transmitter^ 
15 (57), under control of IC (38), having an allocation of transmission media resource (61) for 
reception by receiver (54). IC (36) has transmitter (52) and transmission media resource (53) 
allocated for reception by receiver (50) at IC (38). This transmission plan may represent an 
asymmetric transmission, Le. 9 the outbound channel from IC (38), represented at transmitter 
(57), has more media resources allocated which may indicate a higher bandwidth or higher 
20 data rate for reception by IC (36) through receiver (54) than the outbound channel from IC 
(36) through transmitter (52) through transmission media resource (53) for reception by 
receiver (50) to IC (38). Other representative permutations of the transmission plans 
employed herein are shown in Fig. 19 through the mapping transmission plan (43). 

Fig. 20 demonstrates the timing of how a representative transmission plan may be 
25 implemented by the management component. The transmission plan implementation begins 
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with management component (100) having a predetermined command (102) to send to the 
network at a predetermined command time (1 10). Command(s) (102) is sent to IC (104) that 
must change transmission resource allocation at the implementation time. This command is 
stored in IC (104) and the time to implement the command is decoded by IC (104). IC (104) 
5 then sends a command acknowledgment (118) back to a management component (100). At 
this juncture, command (102) is loaded and awaits deployment at MC (100) at the 
predetermined command time (110). Command (102) is resent (122) if acknowledgment of 
receipt of command (1 18) is not received before a predetermined time. 

It is understood that MC (100) may have a list of every IC (104) in the network that 
10 must change. This list may include the TCP/IP address for each IC (104) so MC (1 10) may 
send a UDP/IP message with a command (102) encoded therein. An acknowledgment 
deadline (134) is included that may be seconds before the implementation time for the new 
transmission plan. The acknowledgment deadline (134) may be the last time at which MC 
(106) can abort an implementation if each IC (104) does not acknowledge the commands. 
15 It is understood that IC (104) may use a coordinated implementation to assure that no 

IC (104) is stranded when the transmission plan is implemented. During the abort sequence, 
which occurs if IC (104) has not acknowledged command (102) at step (118), MC (106) 
sends an abort message (126) to IC (108) that were sent command (102). IC (108) may send 
an abort acknowledgment (128). Abort command (126) is resent at step (130) if it is not 
20 acknowledged. The implementation time (136) defines a time at which the transmission plan 
is executed by IC (104). It is understood that at that point, all necessary ICs (104) have 
acknowledged command (118) and are counting down in a synchronized fashion to the 
predetermined implementation time (136). It is understood that the command acknowledged 
may include an indication of the time at which an IC (104) received command (102) to verify 
25 that the implementation time (136) is synchronized among each IC (104). Once all 

-26- 

5DOCID: <WO 9938274A1_I_> 



WO 99/38274 PCT/US99/01317 

commands have been acknowledged and the network is ready to implement the plan, at 
implementation time (136), the ICs (104) implement the command(s) received from MC 
(100) at implementation time (136). 

At this point, a new transmission plan, as depicted in Fig. 19, may be implemented by 
5 the network. The communication path between MC (30) and ICs (32, 34, 36, 38, 40) is 
independent of the transmission media resources. As depicted in Fig. 19, a transmission path 
(31) is generally over a TCP/IP network (e.g., the Internet), as widely known in use today. 
However, it is within the scope of the present invention to define a guard or maintenance 
channel which may be a point-to-multi-point transmission scheme from MC (30) to and from 

10 ICs (32, 34, 36, 38, 40) wherein an IC co-located with MC (30) assures that a network 
connection is present between ICs (32, 34, 36, 38, 40) and a MC allocated transmitter, such as 
transmitter (44). In such a case, each IC (32, 34, 36, 38, 40) ready to implement the new 
transmission plan may have a receiver dedicated to monitor transmitter (44) to receive abort ,, 
command (126) if each IC (32, 34, 36, 38, 40) does not acknowledge. This assures a fail safe 

15 or guard channel back-up plan to abort implementation of a new transmission plan if one or ; 
more IC (32, 34, 36, 38, 40) loses communication with the management component 

Commands may enter the IC (150) from a plurality of sources, one of which may be 
directly from the MC. Node (158) may be a UNIX daemon or a Windows NT™ service 
which monitors a TCP/IP address. Thus, commands from MC (156) may enter IC (150) 

20 through a port (204). Upon entering IC (150), network commands may be mapped at step 
(158) in conjunction with configuration database information to output specific commands 
(178) to the network equipment. These commands may be put into a command queues (168, 
180, 184) which is then directed through a scheduler process 162, 170 and 186. For example, 
scheduled command implementation processes (162, 170, 186) may output commands to the 

25 appropriate receiver, transmitter or network device through a serial port (164, 166, 172, 174) 
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or a parallel port (188, 190). Command queues (168, 180, 184) may be a polled or interrupt 
driven queue. That is, the schedule command implementation process (164) may periodically 
poll queues (168, 180, 184) to determine whether a command is present, and if so, pass the 
command on to the appropriate network device interfaced (e.g., serial device driver (164, 
166)) or the command key may be a period. 

The command queue may alternatively be interrupt driven. That is, when a command 
enters queue (168, 180, 184), for example, command queue (168) may send an interrupt to the 
command implementation process for the command implementation process to service the 
command and then pass it to the appropriate network device at the appropriate serial port. It 
is understood that this process may be used for implementation processes (170, 186) as well. 

Command implementation processes (168, 170, 186) may be synchronized to network 
time (202) to execute commands at the appropriate time. That is, implementation of 
transmission plans may be synchronized with network time (202) to assure that all network 
devices reconfigure themselves simultaneously or near simultaneously. Implementation 
processes (168, 170, 186) may also have data from configuration database (152) to configure 
implementation process (168, 170, 186) for the particular end-user network device. This 
provides flexibility in implementation process (168, 170, 186). That is, the implementation 
may be written as a modular software program which may be modified by configuration 
database data (160) as implementation process (168, 170, 186) executes. Further to this 
concept is that MC (156) may address configuration database (152) via link (204) to change 
configuration database (152) to redefine the end-user equipment. This allows the MC (156) 
to manage the end-user equipment remotely from the user location at the IC site. IC (150) 
may communicate through module (158) via link (182) to send acknowledgments (200) back 
to the MC (156). Command acknowledgments (118) shown in Fig. 20 and order 



-28- 



9938274A1_I_> 



WO 99/38274 PCT/US99/01317 

acknowledgments may also be used. Figs. 21-28 illustrate a step that may be used to confirm 
receipt of commands or to confirm receipt of an abort command. 

It is understood that there are at least two ways in which to map MC commands or at 
least two ways in which to map MC commands to the end-user device or to a particular port 
5 on a IC. First, a TCP/IP address is provided for the IC in command (204) and then, within the 
UDP command, is a sub-address that may be decoded at (158) addressed to a particular end- 
user device. 

Fig. 22 shows a graphical block diagram of an audit control process by which the 
present invention may collect data from network equipment. Equipment controller (150) may 

10 have a configuration database (152) which controls the configurations of the IC in relation to 
the end-user network equipment. An audit request (252) may be received from the MC via 
port (254). Port (254) may be a user data packet via a TCP/IP network to a particular 
predetermined address at (256). At (256), an auto request command may be decoded to map 
an equipment name to hardware identification from those stored in configuration database 

15 (152). The process at (256) may also be used to map equipment attributes to data controls* 
(290). These parameters may be passed to the reformat command process at (280) which is 
used to provide a formatted audit response (282) to the MC. 

In one embodiment of the present invention, the MC may establish an asynchronous 
data collection process (262, 264, 266) for the network equipment at a respective data port 

20 (268, 270, 272, 274, 276, 278) for the network equipment. Asynchronous data collection 
process (262, 264 266) may be interrupt or poll driven. 

In the interrupt driven embodiment of asynchronous data collection process (262, 264, 
266), the end-user device may send out an unsolicited command via the respective device 
(e.g., device 268), to asynchronous data collection process (262, 264, 266). The interrupt 

25 then invokes the program to service the data condition (or possibly an alarm) from the 
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network equipment. Asynchronous data collection process (262, 264, 266) then moves the 
data to the data control store block (258) where the alarm or data condition may be stored in 
the IC. It is understood that the data control store block (258) may be a hard drive or other 
long term storage means available at the BIC. In a preferred embodiment, the data control 
5 store is a non-volatile data storage media and the asynchronous data collection process is a 
modular program because it is modified from data from configuration database (260) for the 
particular network device. This provides a flexible programming methodology for the 
asynchronous data collection process employed in the present invention. 

In the polled embodiment of asynchronous data collection process (262, 264, 266), 

1 0 asynchronous data collection process (262), for example, may periodically pole the end-user 
network device attached to, for example, port (268), to receive data or alarm conditions from 
the end-user device. The polling rate may be a parameter from the configuration database 
received via link (260). 

In sum, an audit request may be received via port (254) and decoded at (256) to output 

15 data from the data control store program (292). Data output from the data control store may 
be formatted at (280) from parameters past (290) from the audit request. This can provide an 
auto response (294) back to the BMC (282) in the appropriate and predetermined format 

Fig. 23 shows a logic flow representation of a network audit from a MC (302). In Fig. 
23, the MC (302) may establish an auto time for a network element, a transmitter or receiver 

20 (300). At the appropriate time, MC (302) may send out an audit request (306). It is 
understood that audit request (306) is directed to the network element and the particular IC 
controlling that element (308). The IC may then query the network element and send an audit 
reply (312) to the MC (310). Audit reply (312) is shown in time synchronization (316) after 
audit request (306). 
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Initialization or configuration files may be used to implement the invention. 
Exemplary initialization files are shown in Appendices A-H. For example, a "command.ini" 
file (shown in Appendix A) may be used to provide user interface command definitions for all 
network management system equipment supported. The "command.ini" file specifies the 
5 menus associated with each control used on a user display. 

A "monitor.ini" file (shown in Appendix B) may be used to specify automatic 
monitoring functions performed by an equipment controller. The "monitor.ini" file may act 
as the network management system data connection interface definition file. 

An "equipctl.ini" file is shown in Appendix C. The "equipctl.ini" file may be used 
10 as the network management system controller initialization file. That is, the "equipctl.ini" 
file specifies some global parameters for the equipment controller application. It may also 
specify the location of other configuration files if such files are not stored in a default or pre- 
determined location. 

Appendix D shows an exemplary "eventini" file. The "eventini" file may provide. 
15 descriptions of network management system events. For example, the "eventini" file may < 
specify textual responses (to user commands) displayed on a user interface and the 
asynchronous messages sent to either an event logger or other device. 

A "portini" file (shown in Appendix E) may be used as the network management 
system external connection definition file. The "portini" file may specify particular serial 
20 and parallel ports used by the equipment controller application. 

Appendix F shows an example of a "serial.ini" file. The "serial.ini" file may be used 
as the network management system serial command description file. This file may specify 
the command and response strings used to communicate with the manage equipment over a 
serial interface. 
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An example of a network management system user interface definition file 
("panel.ini" file) is shown in Appendix G. The "panel.ini" file may be an the overall 
specification for the display controller presentation. This file ties together the display 
controls with specific input/output ports and describes the total graphic user interface for an 
5 equipment controller site. 

Appendix H shows an exemplary t4 template.ini" file. The "template.ini" file may be 
used as the network management system display template description file. This file specifies 
the graphic qualities of the controls used in the display controller presentation. Graphic 
qualities may include the position of the graphic control on a display, the type of display 
10 object, the name of any required bitmap graphic file, and a reference to any menu associated 
with the control. 

The hardware identification field (1510) may contain information that identifies a 
specific transmitter or receiver at a site. The hardware identification field may have the 
format: 

1 5 H WID=<Class> : <Name> 

where 

<Class> is the type of hardware and 

<Name> is the name assigned to a specific piece of hardware in the IC configuration. 
The type of hardware may be one of the following classes: 

20 □ Transmitter (TX) 

□ Receiver (RX) 

□ Upconverter (UC) 

a Downconverter (DC) 

25 The <Class> portion of the hardware identification field may be one of the mnemonics 

shown in parentheses. Information fields (1524) and header fields (1528) may share some 
similarities. Each type of field is terminated with an ASCII linefeed (LF) character (1512, 
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1522). The primary difference between header fields (1528) and information fields (1524) is 
that the same header fields are found in all system messages while different messages can 
have different information fields. 

Because of the size of information fields (1524), the format of an information field is 
5 more complex than the format of a header field. Information fields may match the format: 

<mnemonic>=<value> 

where 

<mnemoniO is a mnemonic representing the field type and 

<value> is a string representation of the field value. 
1 0 Both the mnemonic and the value of an information field may consist of printable ASCII 
characters. However, the ASCII character '=* is used to separate the mnemonic and value 
portions of an information field. Therefore, cannot be present is either the mnemonic or 
value strings. 

A transmission control order (TCO) is sent from management component to an IC to 
15 request parameter changes for a transmitter or receiver controlled by the IC. 
A TCO may have has the following information fields: 

□ Execution time 

□ Model parameters 

20 - The execution time field specifies the time at which the TCO must be implemented. 

The TCO for each side of a communication link (transmitter and receiver) may have the same 
execution time to minimize the time the carrier is down during the change. Execution times 
may be given in UTC. The execution time field may have the format: 
ET=<YYYY><MM><DD><hh><mm> 

25 where 
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<YYYY> is the four-digit year number (0000 to 9999), 
<MM> is the two-digit month number (January is "01", etc.), 
<DD> is the two-digit day of the month (01 to 3 1), 
<hh> is the two-digit hour of the day (00 to 23), and 
<mm> is the two-digit minute of the hour (00 to 59). 



All of the fields in a TCO after the execution time are model parameters. These fields 
are the parameter values for the transmitter or receiver specified by the hardware 
identification field of a TCO. Model parameters are specified as a parameter/value pair. The 
1 0 format of a model parameter in a BMF message is: 
<mnemonic>=<value> 

where 

<mnemonic> is the mnemonic for a model parameter and 
<value> is a string representation of the parameter value. 

15 

An abort order (ABRT) may be sent to an IC to cancel any pending TCO for the 
specified hardware. An ABRT does not require any information fields. 

An acknowledgment (ACK) informs the management component that the IC received 
the TCO or ABRT. An ACK is the response message for a TCO or ABRT. When an IC 

20 receives a TCO or ABRT, it must send an acknowledgment to the management component. 
If the IC detects any problems with the TCO (configured hardware does not support a model 
parameter, hardware ID invalid, etc.) then the ACK will describe the problems. An ACK for 
an ABRT does not require this problem description. An ACK may have the following 
information fields: 

25 □ Execution time (same as in TCO) 
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□ Model parameters (only if an error condition exists) 

An ACK may have the same information fields as the TCO that is being 
acknowledged. However, model parameter fields are only present if the IC cannot fulfill that 
5 model parameter. For example, if the TCO contained an invalid receiver bit rate but a valid 
receiver frequency then the ACK would include an information field for the RXR model 
parameter but not for the RXF model parameter. 

An audit request (AREQ) is sent periodically by the MC for each transmitter and 
receiver in a satellite network. Each AREQ is sent to the BMF IC responsible for managing 
10 the specified transmitter or receiver. An AREQ does not require any information fields. 

An audit response (ARSP) is sent by an IC in response to an AREQ from the MC. An 
ARSP is the response message for an AREQ. An ARSP has the following information fields: 

□ Execution time (time ARSP generated) 

□ Model parameters (actual settings) 

15 

The format of an ARSP may be almost identical to the format of a TCO: the message 
contains an information field for all of the model parameters pertaining to the specified piece 
of hardware. However, the values of the model parameters may be the actual settings of the 
hardware, not the desired settings. 

20 One purpose of the ARSP is to determine the state of the hardware in the network. A 

secondary purpose is to check for manually instituted changes to the configuration of the 
network hardware. For example, an operator at a remote site might manually change the 
receiver frequency using the front panel of the equipment. The management component 
periodically requests the current state of all managed equipment to check for parameter 

25 modifications not initiated by the management. The execution time for an audit response is 
the time at which the ARSP is generated. 
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An ARSP may contain the model parameters for the type of equipment specified by 
the hardware identification. When the value for a model parameter is not available, the value 
portion of the field may be "UNKNOWN". For example, if the scrambling state of a 
transmitter cannot be determined by an IC, the field "SCR=UNKNOWN" may appear in the 
5 audit response. 

The IC (IC) may read its configuration files at startup and construct memory resident 
database tables and data 'objects' to facilitate rapid access to the configuration information 
stored in those files. Among the data read from the configuration files are the records that 
describe the equipment that the Management Console (MC) application will attempt to 
1 0 control by its commands to the Equipment Controller. The MC may communicate with the 
Equipment Controller in message with a format similar to: 



Equip=EquipmentClass:EquipmentUnitName 
Attribute l=Valuel 
15 Attribute2=Value2 

where 'EquipmentClass' and 'EquipmentName 1 are character string values that occur in the IC 
configuration files as identifying a piece of modeled equipment. The values of 'Attribute' and 
'Value' are also represented as character strings and hence the entire dialog between the MC 
20 and IC is through text based messages. 

The IC configuration files identify one or more pieces of modeled equipment and a set 
of attributes that the modeled equipment can support. For example, the following section of 
an 'equipctl.ini' file describes an equipment element known as 'TRANSMITTERrOutbound*. 
The modeled attributes are identified by the 'EquipModemAttrsl entry and list the values TXF 
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TXR MODT MODR ENCT ENCR DENC SCR PWR CXR as the legitimate attributes of the 
unit known as TRANSMITTER:Outbounci'. 



[Outbound] 
5 EquipName=Outbound 

EquipClass=TRANSMITTER 

EquipModelAttrs=ALL TXF TXR MODT MODR ENCT ENCR DENC SCR PWR CXR 
EquipAttrSetCmds="" EFDataTxfSetCmd EFDataTxrSetCmd EFDataModtSetCmd 

EFDataModrSetCmd EFDataEnctSetCmd EFDataTxrSetCmd EFDataDencSetCmd 
10 EFDataScrSetCmd EFDataPwrSetCmd EFDataCarrierSetCmd 

EquipAttrSetCmdParms="TXF TXR ENCT PWR" "TXF" "ENCR TXR" "MODT" "MODR" 

"ENCT" "ENCR TXR" "DENC" "SCR" "PWR" "CXR" 
EquipAttrSetCmdPorts=Serial5 
EquipAttrSetCmdAddrs=" 1 " 
15 EquipAttrMonConns="" EFDataTxfMon EFDataTxrMon EFDataModtMon 

EFDataModrMon EFDataEnctMon EFDataEncrMon EFDataDencMon 
EFDataScrMon EFDataPwrMon EFDataCarrierMon 
- EquipAttrMonConnPorts=Serial5 
EquipAttrMonConnAddrs-' 1 " 
20 AssociatedEquipment=RECEIVER:Demod 1 

This configuration entry may also associate other configuration entries with the 
equipment attributes that permit the equipment controller to set (modify) and get (recover) the 
attribute values from an actual piece of serially attached equipment. The entries in the list of 
25 'EquipAttrSetCmds' refer to entries in the 'serial.ini' file that describe the actual command to 
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be sent. The entries in the 'EquipAttrSetCmdPcrts' and 'EquipAttrSetCmdAddrs' describe 
which serial port the attached equipment is connected to and the address of the attached 
equipment (in the case that multiple pieces of equipment are attached via the same serial 
port). Similarly, the 'EquipAttrMonConns' entry refer to configuration entries in the 
5 'monitor.ini' file that describe the mechanism by which the attribute is recovered from the 
attached equipment and the 'EquipAttrMonConnPorts' and 'EquipAttrMonConnAddrs* 
describe the serial ports and addresses used for data recovery. 

Hence the IC is in not actually aware of the semantics of the data values it is 'setting' 
or 'getting' and the mapping between the equipment and equipment attributes that the MC 
1 0 believes it is controlling is completely defined by the equipment controller configuration files 
and not equipment controller software. 

The MC and IC communicate via the text format generally described above. All 
communication is initiated by the MC. Three request packets are currently defined: 1) a 
request to modify the attributes of a particular piece of equipment at a particular time in the 
1 5 future, 2) a request to cancel the request to modify the attributes of a particular piece of 

equipment, and 3) a request to return the current values of the attributes of a particular piece 
of equipment. Each request is normally responded to with a complementary message. In 
some cases, however, no response message purposely generated in order to communicate a 
negative response. 

20 The request to modify the attributes of a particular piece of equipment is known as a 

Transmission Change Order (TCO). The format of a TCO is as follows: 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 
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Time=YYYYMMDDHHMM 
Attributed Value 1 
Attribute2=Value2 



5 When the IC receives a TCO it validates the request. The request validation includes 

confirming that the requested change time has not already past and that the IC configuration 
supports the requested modifications. The IC may refer to its memory resident database of 
configuration data to validate request. First, the IC may insure that the requested equipment 
is identified in the configuration. It then may insure, by tracing the attributes named in the 

1 0 request through the configuration to the commands that must be issued to insure that 

sufficient configuration information is present to form the required commands. Finally it may 
check to see if the equipment is currently responding to commands. 

If an error is detected such that the request cannot be supported by the configuration, a v > 
response may be returned to the MC identifying the offending request data. For example, if a *,< 

15 request contained an equipment identification that did not exactly match an entry in the 

'equipctl.ini' file or if an attribute name did not exactly match one of the legitimate attributes 
named in the 'equipctl.ini 1 file, a response would be sent indicating why the TCO was invalid 
and implicitly indicating that the request would not be implemented. Further, if a legitimate 
attribute is named, but the equipment controller finds that either no serial command is 

20 referenced or that the referenced serial command is not configured, the IC may also send a 
similar response indicating why the request cannot be implemented. Validation of the 
parameter values may also be accomplished in a similar technique. 

If the request is otherwise correct, but the equipment is currently not responding to 
serial commands, no response is purposely generated, which may indicate that no problem 

25 was detected in the request but that the since no acknowledgment was sent, the request will 
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not be implemented at the specified time. Otherwise, an acknowledgment is returned to the 
MC indicating that unless otherwise instructed, the IC will perform the requested 
configuration change at the requested time. The request to cancel the modification of the 
attributes of a particular piece of equipment is known as a Abort Message (ABRT). The 
format of an ABRT is as follows: 

ABRT 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 

The IC may remove the outstanding command set to be issued to the specified 
equipment if any command is queued and may send an acknowledgment to the MC indicating 
it has done so. If, at the time of receipt, no command is outstanding, the IC may respond with 
a message indicating that no command was found. The request to recover the current values 
of the attributes of a particular piece of equipment is known as an Audit Message (AUDIT). 
The format of an AUDIT is as follows: 

AUDIT 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 
AttributeName (optional) 
AttributeName (optional) 

The MC may request the current values of the equipment attributes by sending an 
AUDIT message to the IC. The message may contain specific attribute names or, in the 
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absence of any attribute names, all attributes assuciated with the equipment are returned. 
Should the equipment or attributes identified not be defined in the IC configuration, the IC 
will send a message similar to the negative acknowledgment to a TCO indicating what 
particular field of the request message was found in error. If the AUDIT request message is 
5 found to be supported by the current IC configuration, the IC may will use the configuration 
entries identified by the 'equipctl.ini' file to recover the current values and will form a 
response message similar to the TCO message and send it to the MC. The response message 
format is as follows: 



10 AUDIT 

MessageSequenceNumber 

Equip=EquipmentClass:EquipmentUnitName 

Time=YYYYMMDDHHMM 

Attributel=Valuel 
1 5 Attribute2=Value2 

The Implementation component (IC) reads its configuration files at startup and 
constructs memory resident database tables and data 'objects' to facilitate rapid access to the 
configuration information stored in those files. 
20 Among the data read from the configuration files are the records that describe the 

equipment that the Management Console (MC) application will attempt to control by its 
commands to the Equipment Controller. The MC will communicate with the Equipment 
Controller in message with a format similar to: 
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Equip=EquipmentClass:EquipmentUnitName 

Attribute l=Valuel 

Attribute2=Value2 



5 where 'EquipmentClass' and 'EquipmentName' are character string values that occur in the IC 
configuration files as identifying a piece of modeled equipment. The values of 'Attribute' and 
'Value' are also represented as character strings and hence the entire dialog between the MC 
and IC is through text based messages. 

The IC configuration files identify one or more pieces of modeled equipment and a set 
1 0 of attributes that the modeled equipment can support. For example, the following section of 
an 'equipctl.ini' file describes an equipment element known as TRANSMnTERiOutbound'. 
The modeled attributes are identified by the 'EquipModemAttrs' entry and list the values TXF 
TXR MODT MODR ENCT ENCR DENC SCR PWR CXR as the legitimate attributes of the 
unit known as 'TRANSMITTER: Outbound'. 

15 

[Outbound] 

EquipName=Outbound 
EquipClass=TRANSMITTER 

EquipModelAttrs=ALL TXF TXR MODT MODR ENCT ENCR DENC SCR PWR CXR 
20 EquipAttrSetCmds="" EFDataTxfSetCmd EFDataTxrSetCmd EFDataModtSetCmd 

EFDataModrSetCmd EFDataEnctSetCmd EFDataTxrSetCmd EFDataDencSetCmd 
EFDataScrSetCmd EFDataPwrSetCmd EFDataCarrierSetCmd 

EquipAttrSetCmdParms="TXF TXR ENCT PWR" "TXF" "ENCR TXR" "MODT" "MODR" 
"ENCT" "ENCR TXR" "DENC" "SCR" "PWR" "CXR" 
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EquipAttrSetCmdPorts=Serial5 
EquipAttrSetCmdAddrs=" 1 " 

EquipAttrMonConns= ,,n EFDataTxfMon EFDataTxrMon EFDataModtMon 

EFDataModrMon EFDataEnctMon EFDataEncrMon EFDataDencMon 
5 EFDataScrMon EFDataPwrMon EFDataCarrierMon 

EquipAttrMonConnPorts=Serial5 
EquipAttrMonConnAddrs- ' 1 " 
AssociatedEquipment=RECEIVER:Demodl 



10 This configuration entry also associates other configuration entries with the equipment 

attributes that permit the equipment controller to set (modify) and get (recover) the attribute 
values from an actual piece of serially attached equipment. The entries in the list of 
'EquipAttrSetCmds* refer to entries in the 'serial.ini* file that describe the actual command to ? 
be sent. The entries in the 'EquipAttrSetCmdPorts' and 'EquipAttrSetCmdAddrs' describe 

15 which serial port the attached equipment is connected to and the address of the attached 
equipment (in the case that multiple pieces of equipment are attached via the same serial 
port). Similarly, the 'Equip AttrMonConns' entry refer to configuration entries in the 
'monitor.ini' file that describe the mechanism by which the attribute is recovered from the 
attached equipment and the 'EquipAttrMonConnPorts' and 'EquipAttrMonConnAddrs 1 

20 describe the serial ports and addresses used for data recovery. 

Hence the IC is in not actually aware of the semantics of the data values it is letting 1 
or 'getting 1 and the mapping between the equipment and equipment attributes that the MC 
believes it is controlling is completely defined by the equipment controller configuration files 
and not equipment controller software. 
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The MC and IC communicate via the text format generally described above. All 
communication is initiated by the MC. Three request packets are currently defined: 1) a 
request to modify the attributes of a particular piece of equipment at a particular time in the 
future, 2) a request to cancel the request to modify the attributes of a particular piece of 
5 equipment, and 3) a request to return the current values of the attributes of a particular piece 
of equipment. Each request is normally responded to with a complementary message. In 
some cases, however, no response message purposely generated in order to communicate a 
negative response. 

The request to modify the attributes of a particular piece of equipment is known as a 
10 Transmission Change Order (TCO). The format of a TCO is as follows: 



TCO 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 
1 5 Time= YY Y YMMDDHHMM 
Attributed Value 1 
Attribute2=Value2 

When the IC receives a TCO it validates the request. The request validation includes 
20 confirming that the requested change time has not already past and that the IC configuration 
supports the requested modifications. The IC refers to its memory resident database of 
configuration data to validate request. First the IC insures that the requested equipment is 
identified in the configuration. It then insures, by tracing the attributes named in the request 
through the configuration to the commands that must be issued to insure that sufficient 
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configuration information is present to form the required commands. Finally it checks to see 
if the equipment is currently responding to commands. 

If an error is detected such that the request cannot be supported by the configuration, a 
response is returned to the MC identifying the offending request data. For example, if a 
5 request contained an equipment identification that did not exactly match an entry in the 

'equipctLini 1 file or if an attribute name did not exactly match one of the legitimate attributes 
named in the 'equipctLini' file, a response would be sent indicating why the TCO was invalid 
and implicitly indicating that the request would not be implemented. Further, if a legitimate 
attribute is named, but the equipment controller finds that either no serial command is 
10 referenced or that the referenced serial command is not configured, the IC will also send a 
similar response indicating why the request cannot be implemented. Validation of the 
parameter values may also be accomplished in a similar technique. 

If the request is otherwise correct, but the equipment is currently not responding to 
serial commands, no response is purposely generated, indicating that no problem was detected • , : 
15 in the request but that the since no acknowledgment was sent, the request will not be 
implemented at the specified time. 

Else an acknowledgment is returned to the MC indicating that unless otherwise 
instructed, the IC will perform the requested configuration change at the requested time. 
The request to cancel the modification of the attributes of a particular piece of 
20 equipment is known as a Abort Message (ABRT). The format of an ABRT is as follows: 

ABRT 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 
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The IC will remove the outstanding command set to be issued to the specified equipment if 
any command is queued and will send an acknowledgment to the MC indicating it has done 
so. If, at the time of receipt, no command is outstanding, the IC will respond with a message 
5 indicating that no command was found. 

Figure 13 depicts a flow chart of a transmission plan execution. Initially, the system 
may have an unscheduled transmission (1302). The transmission plan may be assigned an 
execution time (1304). The transmission plan may be propagated to the network to place the 
plan onto a pending status (1306). After all of the TCO's required to implement the 

1 0 transmission plan have acknowledged the command, the transmission plan is ready for 
execution (1308). At the transmission plan execution time (1310) the plan began the start 
sequence. After the MC confirms that all TCO's have been confirmed, e.g., so that the MC 
does not issue an abort command, the transmission plan goes active (1312). 

The system then begins normal operation on the new transmission plan and the system 

15 begins collecting data again on link usage (1316). Special transmission plans, e.g., 
transmission plans that are not recurring, are not re-scheduled (1318). 

Figure 14 depicts a bandwidth allocation request. This control loop may execute at 
the MC. The system may receive a request for bandwidth 1402 from the Bandwidth 
administrator or an IC. The request may be an unscheduled network event 1404. The request 

20 for bandwidth is decoded and scheduled for execution 1406. The execution schedule may be 
for immediate execution or for a scheduled deployment. The appropriate TCO may be sent 
from the MC to the appropriate IC to propagate the transmission plan and to put the plan into 
the ready state 1408. The transmission plan then waits for its execution time. When the 
transmission plan execution time arrives (1410) the MC confirms that the TCO's were 
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confirmed by the ICs. If the TCO's were confirmed, the plan goes active (1412) at the 
predetermined time, the system has thereby fulfilled (1414) the bandwidth request. 

The IC may implement a control loop similar to that shown and described above. The 
IC may confirm that a channel is available within the present transmission plan 1406 and 
5 immediately execute the new transmission pan 1408, 1410 and 1412. The IC may then notify 
the MC 1402 of the unscheduled 1404 transmission plan. The MC may then proceed as 
described above to propagate and deploy the new plan. 

Figure 5 depicts the inter-process communication between the MC 502 and ICs (506) 
and 542. MC commands are sent via the UDP/IP link 504 from the control component 503 to 
10 the equipment control component 514. The equipment controller 514 then maps the generic 
network commands from the MC to specific commands (discussed above) for output (512) to 
the managed equipment (510). The equipment controller (514) may lose the command event 
(524). The IC may also denote the command event on the local display 530. 

The system may receive alarm and other network messages that may effect the 
1 5 network management display 5 1 8 via the TCP/IP connection 516. Equipment controller 514 
may connect to the display controller 518 when the equipment controller 514 receives an 
alarm condition from the network equipment (510,520) via command links (512, 522). The 
event logger (534) may receive network audits and network events from the IC 506 
equipment controller (514) via UDP/IP link 532. As provided above, each of the 
20 communication processes on Figure 5 may be interpret or poll driven. 

The IC may also denote the command event on the local display 530. 
The system may receive alarm and other network messages that may effect the 
network management display 518 via the TCP/IP connection (516). Equipment controller 
(514) may connect to the display controller (518) when the equipment controller 514 receives 
25 an alarm condition from the network equipment (5 1 0,520) via command links (512, 522). 
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The event logger (534) may receive network audits and network events from the IC 506 
equipment controller (514) via UDP/IP link (532). As provided above, each of the 
communication processes on Figure 5 may be interrupt or poll driven. 

Other embodiments and uses of the invention will be apparent to those skilled in the 
5 art from consideration of the specification and practice of the invention disclosed herein. The 
specification and examples should be considered exemplary only. The scope of the invention 
is only limited by the claims appended hereto. 
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1 . A system for controlling a network of communication terminal comprising: 
a management component; 
5 an implementation component, said implementation component in communication with said 
management component to receive at least one transmission plan, said transmission plan 
containing a scheduled implementation time, said implementation component receiving said 
transmission plan, decoding an implementation time for said transmission plan and outputting 
command to network component at said implementation time to implement said transmission 
10 plan. 



2. A method for managing a communication network with an adaptive transmission plan 
comprising: 

analyzing network bandwidth allocation over a predetermined period of time; 
15 determining a transmission plan to accommodate, at least in part, the results of said analysis 
of said network bandwidth allocation; 

deploying said transmission plan to a plurality of network component to implement said 
transmission plan; and 

analyzing network bandwidth allocation short falls over a predetermined period of time to 
20 identify a transmission plan that accommodates bandwidth demands. 
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3. A method for facilitating network management in a multiple vender network 
comprising: 



receiving a generic network command at an implement component; 
5 decoding said generic network command; 

translating said decoded generic network command to specific commands for a particular 
device through a text based file that contains text strings of specific device commands; 
and 

outputting said translated commands to said particular network device. 
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Figure 2. 
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Figure 3. 
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Figure 4. 
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CAPACITY ALLOCATION SYSTEM USING 
SEMI-AUTONOMOUS NETWORK ELEMENTS TO 
IMPLEMENT AND CONTROL A TRANSMISSION SCHEDULE 

FIELD OF THE INVENTION 

This invention relates to communication methods and apparatus for 
providing network management, bandwidth and path control in a heterogeneous 
network that may be composed of multiple vendor equipment and transmission 
5 paths. More specifically, the communication system concerns semi-autonomous 
implementation components within a management hierarchy to globally 
manage multiple vendor elements while satisfying local network demands. 
BACKGROUND OF THE INVENTION 

Telecommunications services have, for many years, attempted to 

10 optimize or minimize bandwidth usage between network elements. Since the 
modern communications era, brought about by the theories of Shannon, 
telecommunications engineers have been keenly aware of the need to provide 
optimal, or at least good solutions, to bandwidth allocation problems in point- 
to-point and point-to-multipoint networks. 

15 In wireless communication systems, solutions to bandwidth allocation 

problems can be seen in the way data is modulated to "share" finite resources. 
For example, time division multiple access ("TDMA") provides a means for 
multiple stations to access time slots on satellite carriers and thereby "share" 
bandwidth resources. Code Division Multiple Access ("CDMA") provides a 
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means to use code division modulation techniques (time and frequency 
modulation) for multiple point access to a predetermined range of bandwidth 
and thereby "share" bandwidth space. Likewise, frequency division multi- 
access ("FDMA") provides a means to divide up and share a finite bandwidth 
5 resource. 

More elaborate schemes to dedicate bandwidth in accordance with a 
predetermined transmission schedule and modulation plan can be seen in U.S. 
Patent No. 5,592,470 to Rudrapatna et al, ("Rudrapatna") issued January 7, 
1997, (the "Rudrapatna patent"). The Rudrapatna patent concerns a terrestrial 

10 micro-port network that allocates bandwidth to terrestrial micro-port receivers 
based on a pre-determined schedule and modulation plan. The pre-determined 
schedule and plan may be subsequently modified by dynamic demands on the 
micro-ports. The network can then satisfy the dynamic demands by moving 
channels between modulation and polarity schemes in pre-determined amounts. 

15 111 wireless networks, certain communications links require more 

bandwidth and power resources than others. This is necessary to maintain 
specified information throughput, to provide appropriate grades of service or 
due to varying site configurations (e.g., different antenna sizes). Whenever a 
change in network resource allocations is required to match varying traffic 

10 requirements, a new transmission plan may or may not be implemented. This 
may necessitate programming, transmitting and receiving communications 
equipment, e.g., amplifiers, modulators and demodulators, to support the new 
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resource assignments. These and other problems in bandwidth allocation in a 
multi-vendor network are addressed by the present invention. 
SUMMARY OF THE INVENTION 

The methods and apparatus disclosed herein may assign and re-assign 
5 available transmission resources in point-to-point, multipoint and broadcast 
wireless networks. This may be accomplished on the basis of information 
capacity and connectivity requirements between transmitters and receivers of 
communications links at the time of assignment or re-assignment. The system 
may also provide a network administrator with novel tools and automated 
10 methods to define and implement network transmission plans and to modify 
allocation decisions as traffic requirements change. 

The system may provide the tools to efficiently allocate transmission 
resources. These tools help implement the communications links that form 
wireless networks. An optimum resource or a "good fit" allocation is achieved 
15 when network users have just enough information transmission capacity to 
perform their tasks. One way to accomplish optimal or good transmission 
resource allocations in a wireless network is to analyze network users' usage 
patterns and allocate capacity according to a time-varying schedule. 

By analyzing network usage patterns, a management component can 
20 determine a transmission plan schedule that efficiently allocates the satellite 
bandwidth available to the network based on historical usage patterns. The 
management component may automatically schedule and implement a 
transmission plan. As the network users' requirements change, the management 
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component may update or modify the scheduled transmission plans to satisfy the 
new requirements. 

The system may automate implementation of transmission plans by 
reprogramming the system when predetermined parameters are reached. For 
5 example, the management component may determine a transmission plan from a 
historical analysis of bandwidth requirements between stations. This 
transmission plan may be automatically deployed to the network. The 
management component can then monitor and analyze network allocation 
demands to determine a new transmission plan. The new transmission plan can 
1 0 then be automatically deployed in the network when predetermined parameters 
are reached, such as, average change in bandwidth, e.g., bandwidth in 
use^andwidth in the transmission plan, exceeds a predetermined amount or if a 
predetermined amount of time has transpired. The transmission plans may be 
propagated as generic network commands and translated into corresponding 
15 equipment parameters and associated control commands as required for 
reconfiguring network equipment elements. Thus, the system may generate and 
distribute equipment configurations to network elements to reprogram for 
synchronized execution at predetermined times. 

The system further controls and schedules bandwidth between network 
20 elements to consider other network factors such as economic constraints. In a 
wireless communications network, each communications carrier should have 
just enough bandwidth and power necessary to meet the needs of its 
corresponding users. Although optimum resource allocation is the primary goal, 
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sub-optimum allocation may be tolerated when economic constraints may limit 
transmission resources to finite amounts. Thus, for example, a dynamic 
bandwidth requirement at a network station may require an increase in 
bandwidth allocation from the station, such as when the queuing depth reaches a 
5 predetermined amount at the station switch. The station may have additional 
capacity available on an available communication link, however, the 
incremental capacity of the link may far exceed the bandwidth required to 
reduce the depth of the communication queue. Furthermore, the financial cost 
of the incremental capacity may exceed the cost of waiting for network usage to 

10 decrease to reduce the depth of the queue. The system, in this case, would allow 
the network to back up and flow control the user data before the system would 
allocate additional capacity. The system provides methods to use finite 
transmission resources by enabling power and bandwidth to be re-allocated as 
needed to meet changing communications requirements in satellite networks. 

15 However, the capabilities of the system are applicable to all wireless networks 
that can be modeled as a collection of transmitters, transmission resources, and 
receivers. 

The system provides a means to manage heterogeneous or multiple 
vendor network equipment over heterogeneous or multiple vendor transmission 
20 resources with multiple transmission paths. One such path may be via 
programmable C-, Ku-, or Ka- band satellite networks. Other paths may be via 
discrete carriers available on a preprogrammed networks such as the Inmarsat, 
Globalstar or Iridium satellite systems. Yet other paths may be via third party 
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medium or broadband networks such as the envisioned Teledesic satellite 
network. Yet another path may be over a programmable or managed network 
such as the Intelsat global satellite system. Thus, the system provides a means 
to define and manage capacity between network elements where the network 
5 may be a combination of a discrete bandwidth allocation network managed by 
an external system, a semi-programmable medium or broadband network 
wherein a varying amount of bandwidth may be allocated from an externally 
managed resource and a fully-programmable network where the resource is 
managed by a network management component. Thus, the management system 

10 provides a nearly transparent means by which an operator, user or network 
element may place demands on the network and the management system may 
satisfy those demands based on a least cost algorithm, quality of service 
parameters and pre-defined or time-varying transmission plans. 

The management system described may configure the transmission 

15 elements (transmitters and receivers) in a wireless network to implement a 
specified allocation of transmission resources according to varying, scheduled or 
ad-hoc capacity requirements. The system maintains a schedule of transmission 
plan implementations and may automatically perform each implementation at a 
scheduled time. 

20 The semi-autonomous network management system essentially consists 

of two semi-autonomous components. The first component is the 
Implementation Component (IC) which executes at a site containing network 
transmission elements and the second is a Management Component (MC) which 
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executes at a network management site. These components may be connected 
via a user datagram Internet protocol messaging format. 

At the heart of the system is the IC. The IC may be a stand-alone 
application program that controls one or more network elements. A network 
5 element may be the station or communication equipment physically controlled 
by an IC. Thus, it is usually the case that the network element is a stationary or 
mobile communications node at a single physical location. The IC may, 
however, remotely control a network element. 

In one embodiment of the present invention, the IC application may 
10 execute in a dedicated processing environment such as a PC executing UNIX or 
other suitable operating system such as Windows or DOS. The IC may also 
execute on an integrated or embedded processor such as a PC on a card 
environment with an application specific or real time operating system 
executing thereon . 

15 The IC is semi-autonomous, e.g., it can translate allocation commands 

from a management component into executable commands for its associated 
network elements without having direct, full-time contact with the network 
management component. The IC may store pre-programmed parameters, 
transmission plans, or collection commands for automatic execution. The IC 

20 may map a network programming language command set or generic allocation 
command to a vendor specific command sequence. The IC may contact the 
management component to receive permission to access network bandwidth, to 
report the unavailability of network elements, or to request different allocation 
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parameters if or when local demands exceed the IC's preprogrammed 
allocations. Thus, the IC may provide independent control over network 
elements while maintaining or executing a management plan. 

In the semi-autonomous network management scheme disclosed, 
5 transmission schedules may be loaded in advance of the implementation of the 
scheduled transmission plans. Then, at a predetermined time, the network can 
switch over to the new transmission plan to implement the optimal, or at least 
, good solution, before more complicated dynamic bandwidth allocation 
algorithms would need to be employed. 

10 In addition to automatically implementing scheduled transmission plans 

generated by the management component, the system may also perform network 
usage analysis. Automated network usage analysis may require that the 
management component have access to traffic data collected for the network. 
The data may be collected automatically or manually by the management 

15 component or the implementation component may interact with the elements in 
the network to collect the usage data. The management component may use 
statistical methods to analyze the gathered network usage data to suggest or 
implement optimize transmission plans for efficient use of the available 
resources according to a schedule. 

20 Efficient use of bandwidth spectrum may be achieved on various levels 

in the system. On a first level, bandwidth may be scheduled in accordance with 
a historical analysis of demands on the network. For example, it may be 
determined that Monday morning traffic is mostly outbound (i.e., from a central 
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earth station to a mobile station). On Fridays, however, most of the traffic is in 
the opposite direction (i.e., from mobile stations back to the central earth 
station). In this instance, an assymetric channel may be opened for Monday 
traffic to provide higher outbound data and a slower speed return path. Then the 
5 opposite allocation may be established for Friday's traffic (e.g., a high speed 
channel from a mobile station to the central station and a low speed 
acknowledgment channel from the central station back to the mobile station). 
This may provide an optimal, or at least a cost-effective solution for the capacity 
requirements at a particular time. 

10 On a second level, the system may allocate capacity based on class of 

service parameters available, for example, through an Asynchronous Transfer 
Mode ("ATM") type packet format. For example, a class of service may 
identify data packets with low priority for a particular application. In such a 
case, an expensive satellite carrier may not be necessary and a lower-cost 

15 transmission resource may be put online by the network to pass the required 
data packets. Thus, the present network can mix class of service bandwidth 
allocation methods with least cost routing decisions based on predetermined 
parameters programmed in the IC. 

The semi-autonomous nature of the network management components 

20 may use a datagram protocol for interprocess communication. More 
specifically, the network components may communicate through the use of the 
User Datagram Protocol ("UDP") over an internet protocol ("IP"). 
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Communication between the management component and the IC may use a 
polled or interrupt methodology. 

In a polled mode, the management component contacts each of the ICs 
to pass UDP/IP messages or to receive Transmission Control Protocol/Internet 
5 Protocol ("TCP/IP") information from the particular IC. In an interrupt driven 
mode, the IC may attempt to communicate with the management component. 
The interrupt mode may be used to re-establish contact with the MC if the IC 
loses synchronization with the network or to pass alarm or other local conditions 
happening at the IC that may not be detected by the management component. In 

10 the interrupt driven mode, the IC may have a preassigned back-up channel or 
predetermined bandwidth allocation to communicate with the management 
component. The management component may be programmed to look for 
alarm conditions or communication attempts from the ICs when predetermined 
parameter thresholds are reached. 

15 Additionally, a signaling control mechanism between the management 

component and the ICs is disclosed. The signaling control mechanize operates 
to ensure that each of the ICs receives the appropriate message(s) and that the 
transmission plan may be implemented according to the predetermined 
schedule. 

20 The signaling control mechanism between management component and 

implementation components may communicate by exchanging the following 
UDP/IP messages. 

• Transmission Control Order 

• Abort Order 
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• Acknowledgment of a Transmission Control or Abort Order 

• Audit Request 

• Audit Response 

5 A transmission control order ("TCO") specifies new transmission 

parameters for a transmitter or receiver. The TCO may also specify the 
implementation time. The implementation time may be the time at which 
elements should begin using the transmission parameters specified in the order. 
TCOs are generated by the system to implement a new transmission plan. The 

10 system sends TCOs to the ICs of transmitters and receivers that must change 
parameters to implement the new transmission plan. TCOs may be stored on a 
hard drive or other non-volatile storage so that they are preserved through IC 
restarts and at IC power failures. 

It is possible that an IC may be down or may not be able to communicate 

1 5 with the managed equipment at the execution time of a TCO. When this 

happens, the IC may implement the current transmission plan or may implement 
a default state when the IC reestablishes communication with the managed 
equipment. 

The IC may send an acknowledgment of a TCO when a TCO is received 
20 from the system. If any of the requested parameter changes cannot be 
implemented because the managed equipment or the configuration files do not 
support it, the IC notifies the management component of this in the 
acknowledgment. 
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The IC may also check that the parameter values are valid for the 
managed network equipment. Parameter ranges are specified in the Equipment 
Controller configuration files in the IC, discussed further below. 

A confirmation message may not be necessary for reporting the 
5 successful implementation of a transmission control order. Because the 
majority of satellite networks implement single links to each remote site, if an 
IC is not able to implement a TCO, the IP connection to the system may be lost 
The system management component may detect the problem from the lack of 
audit responses. If the system does not receive an audit response from an IC, 
10 the system may update the site status and alerts the management component 
alarm. 

An abort order may instruct the IC to cancel any pending TCO for the 
specified transmitter or receiver. The system may send abort orders when a 
pending implementation is canceled by the Administrator. The IC may send an 
15 acknowledgment when it receives an abort order. The IC may send an 
acknowledgment when it receives a TCO or abort order from the management 
component. 

An audit request may be periodically sent to an IC by the management 
component. The management component may send an audit request to check 
20 the status of a transmitter or receiver. One audit request may be sent for each 
transmitter and receiver being managed by an IC. 

An audit response may be sent by an IC when an audit request is 
received from the management component. The audit response may contain the 
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current parameter values for the transmitter or receiver specified in the audit 
request. 

An audit response may be similar in structure to a TCO. It may include 
the hardware identification for a transmitter or receiver and a list of model 
5 parameters and their current values as reported by the physical hardware. 

The receive frequency model parameter may be a special case: the 
frequency reported by the demodulator may not match the commanded receive 
frequency. Sources of frequency error throughout a wireless carrier 
transmission process may result in an offset between the expected and actual 
10 receive frequencies. Many demodulators are designed to accommodate this 
frequency offset by searching for the transmitted carrier in a neighborhood 
around the commanded receive frequency. However, the system may also 
account for this receive frequency offset when determining whether the physical 
hardware is using the same parameters as in the most recently implemented 
15 TCO. 

The management component may periodically request the current 
parameters from all transmitters and receivers. This network auditing function 
may perform the following functions: 

• Maintains the status of communications between the management 
20 component and the transmitters and receivers in the network. 

• Detects parameter changes of the managed equipment. 

When a difference between the specified transmission parameters for a 
transmitter or receiver and the managed equipment is detected, the management 
25 component may notify a Bandwidth Administrator. The management 
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component operator interface may use an audible as well as visual alert to 
improve the chance that a Bandwidth Administrator will notice the difference 
and act to resolve it. 

Fig. 21 shows equipment controller IC (150). IC (150) may have a 
5 configuration database (152) which stores a configuration mapping for end-user 
receiver and transmitter equipment which is interfaced by, for example, serial 
devices (164, 166, 172, 174) and parallel devices (188, 190). The 
receiver/transmitter equipment may be from multiple vendors and thus the 
configuration database (152) maps commands from the management component 
10 (156) to a particular device. This feature of the IC may allow the use of a 
generic network control language in commands sent to IC (150) (discussed 
further below). 

The system is designed to manage all transmission equipment, regardless 
of manufacturer. To achieve this, the management component deals with model 
15 satellite transmitters and receivers as illustrated in Figure 6. 

The transmitter and receiver models have the parameters necessary to 
implement a wireless link. Only parameters that relate to the establishment of a 
wireless link need be included in the transmitter and receiver models. 

The management component may not require information about the 
20 physical equipment elements used to implement the communications links in 
the managed network. Therefore, the MC need not map the model parameters 
directly to commands for the physical hardware of the transmitters and receivers 
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at a site. The IC may have information about the physical hardware at its site 
and may map the model parameters to the appropriate commands and responses. 

The IC may read information about the physical hardware from the 
configuration files. These files may specify the information required by the IC 
5 to monitor and control the managed equipment at a site. The IC configuration 
files may contain the information necessary to convert parameter changes for the 
model transmitters and receivers into commands to the physical hardware. 
BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a pictorial schematic of a star topology satellite network 
10 showing a shared outbound simplex channel and a private inbound simplex 
channel. 

Fig. 2 is a pictorial schematic of a mesh topology for a satellite network 
showing shared outbound simplex channels. 

Fig. 3 is a functional schematic of a transmission equipment model 
15 depicting modulators, up converters, and the loss and gain elements in the 
circuit, the site antenna, and the corresponding receiving circuits showing gain 
and loss elements, the down converter, and the demodulator. 

Fig. 4 depicts software components for the semi-autonomous network 
management system of the present invention. 
20 Fig. 5 is a functional schematic detailing the software components. At 

the control site there is a management (control) component, a display controller 
and an event logger component. At the remote site, there is the IC, the 
equipment controller component and a display controller and event logger 
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component. The management transmission and receiver equipment is further 
shown as being controlled from the IC equipment control. 

Fig. 6 is a functional schematic showing the elements of a transmission 
model that are controlled by the semi-autonomous ICs of the present invention. 
5 Fig. 7 shows a further functional schematic of the IC systems. 

Fig. 8 is a functional schematic showing the software process 
architecture of the semi-autonomous network management component. 

Fig. 9 is a functional schematic of the information flow in the semi- 
autonomous components of the present invention. 
10 Fig. 10 is a graphical depiction of the transmission plan allocation of 

available spectrum. 

Fig. 11 is a graphical depiction of the transmission plans of a 
transmission plan schedule. 

Fig. 12 is a graphical depiction of a transmission plan schedule 
1 5 implemented throughout a particular day. 

Fig. 13 is a flowchart illustrating a method of transmission plan 
deployment and execution. 

Fig. 14 is a flowchart illustrating a method of executing a bandwidth 
allocation request. 

20 Fig. 15 is a graphical depiction of a UDP datagram format employed in 

the management components. 

Fig. 16 is a functional schematic of the request/command flow direction 
of the present invention. 
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Fig. 17 is a flowchart illustrating a method of grading, employing, and 
implementing transmission plans within the network. 

Fig. 18 is a graphical depiction of how the methodology of the present 
invention views transmission media as resources. 
5 Fig. 19 is a graphical representation of the methodology of the present 

invention allocating transmission media resources. 

Fig. 20 is a graphical depiction of a timing transmission plan 
implementation. 

Fig. 21 is a graphical depiction of the command processing flow in the 
10 equipment controller. 

Fig. 22 is a graphical depiction of the process flow for network audit 
processing. 

Fig. 23 is a graphical depiction of the auto command flow with respect 
to timing. 

15 DETAILED DESCRIPTION OF PREFERRED EMBODIMENT 

The system is composed of two software components, the Management 
Component ("MC") and the Implementation Component ("IC") that work 
together to monitor and control the transmission elements in a wireless network. 
The MC includes an operator interface for configuring, monitoring, and 
20 controlling the capacity allocation activity in a wireless network. It may be a 
Win32 application that runs on a Windows NT workstation which may be 
located at a network operations center (NOC). Configuration, monitoring, and 
control of the capacity allocation may be accomplished with the management 
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component. The MC communicates with the other software component the IC, 
using the Internet Protocol (DP) family of network protocols as illustrated in 
Figures 4 and 5. 

The IC is the application that may communicate with the physical 
5 hardware elements implementing the communications links in a wireless 
network. The IC may be a Win32 application that runs on a computer located at 
each site in the network. The IC may read a set of configuration files that 
describe the network equipment to be monitored and controlled. These 
configuration files may be text files and may be created and modified with a text 
1 0 editor program. In general, the configuration files are re-usable, that is the same 
configuration file may be used at multiple sites if the same network equipment 
is used at both sites. 

As discussed above, the MCs and ICs communicate by exchanging IP 
messages. Figure 5 is a representation of the connectivity between the 
15 management component and the IC in a wireless network. The IP connections 
may be implemented on the satellite network, through the Internet, or through a 
private network. A second physical communication path between the MC and 
the ICs may be used to establish IP communications. Typically, ICs do not 
communicate with other ICs; however, communication links may be established 
20 between components to further communication with the MC. 
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The management system is designed around several elements. These are 

the 

• Transmission resource 

• Site 

5 • Transmitter 

• Receiver 

• Transmission element 

• Transmission plan 

• Implementation 
10 • Schedule 

• Execution time 

A transmission resource may be a portion of a wireless capacity (power and 
bandwidth) that may be used by the transmitters in a network. A site may be a 
15 collection of transmitters and receivers controlled by a single IC. Normally one 
IC controls all of the transmitters and receivers at a network site. However, the 
transmitters and receivers at a network site may be controlled by more than one 
IC. For example, this may occur at a hub site in a satellite network with a star 
configuration. 

20 A transmitter is an equipment element that modulates an information 

signal so that it may access a wireless media. A receiver is an equipment 
element that demodulates a signal received from a wireless media to recover the 
information from the broadcast signal. A transmission element may be a 
transmitter or receiver in the network configuration. Although transmitters and 

25 receivers may be different and perform different functions, the management 
component may perform some operations in which transmitters and receivers 
are both treated the same way. For example, the MC may audit the status of all 
transmitters and receivers in the network. The management component may not 
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distinguish between transmitters and receivers when performing this auditing 
operation. 

A wireless link may be created when an information signal is modulated 
by a transmitter and then demodulated by one or more receivers. A wireless 
5 communication network is a collection of communications links that enable 
information transfer among the sites in the network. Each link requires some of 
the transmission resources available to the wireless network. The allocation of 
the available transmission resources among the transmitters in a network is a 
transmission plan. These transmission plans may define the information 
10 capacity and connectivity requirements between the transmitters and receivers in 
the network. 

Only transmitters may need to be specified in a transmission plan. 
Transmitters generate the signals that use transmission resources. The number 
of receivers demodulating a wireless signal does not affect the amount of 
15 transmission resources (bandwidth and power) used to implement the link. 

Implementation may be the process of configuring the transmitters and 
receivers in a wireless network to allocate the transmission resources as 
specified in a transmission plan. The management component may implement a 
transmission plan by sending orders to the ICs controlling the transmitters in the 
20 transmission plan and the receivers listening to those transmitters. These orders 
may specify the transmission parameters for the transmitters and receivers and 
when they should be implemented. The IC may send the equipment-specific 
commands that implement the transmission parameters at the specified time. 
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The implementation schedule may be a list of all transmission plan 
implementations that may automatically be executed in the future. The schedule 
may be maintained by the MC application. An operator may add 
implementations to the schedule, remove implementations from the schedule, 
5 and move existing implementations to different times. An execution time 
consists of a transmission plan and the time at which the transmission will be 
implemented. The time may be a recurring time, for example 1200 UTC every 
day or 0600 UTC every Monday. The implementation schedule may be built 
from execution times. 

10 The information architecture of the system applies primarily to the 

structure of the database maintained by the Management Component and may 
define the structure of the messages exchanged between the management 
component and ICs. 

The information maintained by the management component (network 

15 configurations, transmission resource configurations, transmission plans, etc.) 
may be stored in a relational database. 

The management component may require information about the wireless 
networks that it manages. A network may be viewed as being composed of 
sites, transmitters, and receivers. Information about these objects, e.g., sites, 

20 transmitters and receivers, and the relationships among them may constitute a 
network configuration. A network may be a collection of sites that are linked by 
transmission resources. The following information may be specified for each 
network managed by the system: 
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□ Name 

□ Transmission resources available for use by the network 

The system may maintain the following information for each network: 

□ Network ID 

□ Status 

a Sites in the network 



A site may be the physical location of an antenna in a wireless network. 
10 In addition to an antenna, a site may have at least one transmitter or receiver. 
The system may require that the following information be provided for each 
site: 

□ Name 

□ NMS IP address 

1 5 □ Location (street address, geographic coordinates, etc.) 

□ Contact information (telephone numbers, operators' names, radio 
frequencies, etc.) 

□ Antenna parameters (size, gain, etc.) 



site: 



20 The system may maintain the following information for each 

□ Site ID 

□ Status 

□ Network to which the site belongs 
□ Transmitters at the site 

25 □ Receivers at the site 

□ Time of last management component transmission to site 

□ Time of last IC response from site 



In the system, a transmitter may comprise the equipment necessary to convert a 
30 digital data stream into a carrier for transmission over a wireless resource. The 
system may require that each transmitter be uniquely named. The system may 
maintain the following information for each transmitter: 
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a Transmitter ID 

□ Status (UP, DOWN, FIXED, UNKNOWN) 

□ Site where the transmitter is located 

5 □ Receivers that should be receiving the transmitter' s carrier(s) 

The system may track the status of the transmitters in a wireless 

network. Possible status values for the tracked components may be: 

UP the transmitter is currently generating a carrier and is under 

1 0 the control of the management component 

DOWN the transmitter is not generating a carrier but is under the 
control of the management component 

1 5 FIXED the transmitter is generating a carrier and the management 

component knows the characteristics of the carrier but the 
transmitter is not under management component control 

UNKNOWN the management component does not know if the 
20 transmitter is generating a carrier 

In the system, a receiver may comprise the equipment necessary to 
receive a carrier transmitted over a wireless resource and recover the digital data 
stream. The following information may be specified for each receiver: 

25 □ Name 

□ Transmitter of the carrier the receiver should receive 

The system may maintain the following information for each receiver: 

□ Receiver ID 
30 □ Status 

□ Site where the receiver is located 

A pool may be a collection of transmission resources available for use by 
the managed networks. Each transmission resource is a portion of transmission 
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10 



capacity (power and bandwidth). The following information may be required 
for each pool: 

□ Name 

□ Transmission resources in the pool 

The system may maintain the following information about each pool: 

□ Pool ID 

□ Networks using the pool 

A transmission resource may be a portion of transmission capacity 
(power and bandwidth). The system may require the following information 
about each transmission resource: 

□ Description (transponder, provider, etc.) 

□ Start frequency 
15 □ End frequency 

□ Translation offset 

□ Power allocation 

□ Cost metrics 

20 The system may maintain the following information about each transmission 

resource: 

□ Transmission resource ID 

□ Pool to which the Transmission resource belongs 

25 A transmission plan is an allocation of transmission resources to one or 

more carriers in a wireless network. The system may specify the following 
information about a transmission plan: 

□ Execution time 

□ Duration 
30 □ Comments 
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The system may maintain the following information about a transmission 
plan: 

□ TP ID 

□ State (UNSCHEDULED, SCHEDULED, PENDING, READY, 
5 STARTING, ACTIVE, COMPLETED, or CANCELLED) 

□ BARs satisfied by the TP 

The system may manage sites with multiple transmitters and receivers. 
Therefore the system maintains a naming scheme for identifying a specific 

10 transmitter or receiver at a site. 

Figure 9 may represents the flow of hardware identification information 
from the IC configuration files to the management component. The 
identification information may originate in the configuration files generated for 
a site in a network. The configuration files for a site may be read by the IC. 

15 Figure 9 shows the information flow in the system. Each transmitter and 

receiver at a site may be designated by an equipment class. Each member of a 
class is assigned an instance number. Together, the equipment class and 
instance identify a unique transmitter or receiver at a site. A Bandwidth 
Administrator (902) may supply the hardware identification when configuring 

20 the transmitters and receivers of a site for bandwidth management. The flow of 
information shown in figure 9 simplifies network configuration maintenance 
and reduces the risk of problems due to inconsistent configuration information 
in the network. The circles with a slash (914, 916) illustrate that neither the 
Bandwidth Administrator (902) nor the management component (906) require 

25 access to the configuration files (910). 
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The system software components may exchange information by sending 
and receiving messages using network or external connections. The 
management process may communicate with all of the IC processes. Each IC 
communicates only with the management component. 

The User Datagram Protocol (UDP) of the Internet Protocol (IP) suite 
may be used to transport the inter-process messages. The system may use the 
combination of IP address and UDP port to identify the ICs in the network. Site 
identification information may not be required in the message if the IP address 
and port are already available in the IP and UDP headers. 

The management and ICs may communicate using several types of 
messages. Although each type of message contains different information and 
fulfills a different purpose, the message types share some common 
characteristics as shown in Figure 15. 

□ A message is sent as a single UDP datagram 

15 □ Only ASCII characters are allowed in a message 

□ A message is a series of information fields 

□ Fields are terminated with an ASCII linefeed (LF) 

□ A message is terminated with an empty field (single LF) 

□ The first three fields are the same for any message (message type, sequence 
20 number, and hardware identification) 

Although system messages contain only ASCII characters, the messages may be 
compressed before delivery via UDP. Messages may then be uncompressed 
after receipt. Fields #4 through #N (1514, 1518) in figure 15 are information 
25 fields (1524). The fields prior to the information fields in a BMF message are 
header fields (1528). 



SUBSTITUTE SHEET (RULE 26) 

iDOCID: <WO_9S38274A1_IA> 



WO 99/38274 



-27- 



PCT/US99/01317 



Header fields may be present in system messages (1528). Typically, the 
order and format of the header fields are the same, regardless of message type. 
The format of a header field is simple: a string terminated by an ASCII linefeed 
(LF) character (1504, 1508 and 1510). The string can contain any printable 
5 ASCII character except LF. The management and ICs may communicate using 
the following message types: 

□ Transmission Control Order (TCO) 

□ Abort Order (ABRT) 

□ Acknowledgment (ACK) 
10 □ Audit Request (AREQ) 

□ Audit Response (ARSP) 

The mnemonic in parentheses after each message type is the identifier used 
in the first field (1502) of a system message (1526). After the message type 

15 field, the next field in a system message is a sequence number (1506). The 
management component maintains a sequence number for each piece of 
managed equipment (e.g., receiver or transmitter) in a network. The IC may use 
the sequence number from a request message in the response message. 

Sequence numbers may be used to match responses (ACK or ARSP) 

20 with requests (TCO, ABRT, or AREQ). The use of sequence numbers (1506) 
prevents confusion when multiple responses are received when multiple 
requests were sent due to message delivery delay or temporarily unavailable 
components. 

Figure 18 illustrates a transmission plan for allocating transmission 
25 media resources among transmitters in a network. Figure 18 shows that a 
transmission media can be divided up into discrete segments (10). A network 
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management plan can view discrete segments (10) of bandwidth as discrete 
transmission media sources (12). A transmission plan (16) may be used to map 
a network transmitter (18) through a link (14) to a predefined transmission 
media resource (12). For example, transmission network transmitter (20), in 
5 particular transmitter (18), may be mapped through transmission plan (16) to 
two discrete segments (10) through link (14). Hie network media resource may 
be a star topology as shown in Fig. 1 or a mesh topology as shown in Fig. 2. 

Network transmission media resources may also be on separate 
networks. For example, a first network transmission rsource may be capacity 
10 from the INMARSAT satellite network or through private networks on a C, KU, 
KA or L-Band. The network transmission resources may be further augmented 
by low earth orbiting satellites, medium earth orbiting satellites or 
geosynchronous satellites. Low earth orbiting satellites may be represented by 
the Iridium system employed by Iridium, Inc., whose discrete bandwidth 
15 allocation methodology is herein incorporated by reference. Geosynchronous 
satellites may also provide additional transmission resources as represented by 
the Inmarsat or Intelsat satellite services whose bandwidth allocation 
methodologies are herein incorporated by reference. 

The management component or the ICs do not need to be in direct 
20 control of the bandwidth allocation to utilize transmission media sources. For 
example, bandwidth allocation on the Iridium satellite system may operated 
independently of the management component and the ICs. However, the 
bandwidth allocation methodologies of, for example, the Iridium network, may 
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be employed to treat the resultant communication path as a transmission media 
resource under control of the management component. Indeed, multiple carriers 
from a third-party system may be allocated in discrete predefined units, such as 
discrete segments (10), shown in Fig. 1 8, for utilization by the present invention 
5 as a media resource. 

Fig. 19 is a graphical depiction of network elements, ICs, a management 
component and a transmission plan. A central controller of the present 
invention may be represented by Management Component ("MC") (30). MC 
(30) is in communication with a plurality of ICs ("ICs") (32, 34, 3 8, 40) through 

10 links (31). Each IC may represent a particular site that is under network 
management control by the MC. Each IC may have network equipment (42) 
under its control. For example, IC (40) has transmitter (44) under its control 
and BIC (38) has receivers (46, 48, 50, 51) and transmitters (56, 57) under its 
control. IC (36), however, has receiver (54) and transmitter (52) under its 

15 control. The present invention implements a transmission plan (43) through a 
mapping of network equipment (42) to transmission media resources (46). For 
example, transmitter (44) has been allocated transmission media resource (45) 
for reception by receiver (48) as indicated through up link and down link 
mappings in transmission plan (43). This may represent a combined 
20 transmission media resource whose overall capacity is the entire discrete 
amount allocated at transmission media resource (45). For example, a dynamic 
bandwidth requirement for a connection at a predefined class of service may be 
split into two discrete carriers. The discrete carriers may be represented by the 
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two discrete media resources allocated at transmission media resource (45) to 
provide an overall throughput necessary to accommodate the predetermined 
capacity to support the class of service. The excess capacity may be used to 
provide the time recovered to reassemble the packets at receiver (48). This 
5 methodology is useful in the instance where, for example, a class of service 
from a particular end-user exceeds the network capacity to satisfy the demand 
on a single channel or contiguous media resource. For example, the class of 
service requires a connection that exceeds the bit rate capacity of the modulator 
at a particular transmitter, but two modulators would supply ample bandwidth 
10 for the class of service. In that instance, the IC or the management component 
could divide a packet data stream from the end-user device onto the two 
different modulators. In that instance, multiple transmission media resources 
may be allocated to satisfy the overall class of service demand. 

A further representative example of a transmission plan employed herein 
15 is a broadcast from IC (38) through transmitter (56) which has been allocated 
transmission media resource (57). Transmission media resource (57) may be 
used for reception by both IC (34) and receiver (58) and IC (32) and receiver 
(60). This is an example of a point to multi-point broadcast. The point is 
represented by uplink transmitter (56) and the multi-points are represented by 
20 receivers (58) and (60). One representative application of such a plan is, for 
example, a broadcast message from transmitter (56) to two simultaneous sites 
represented by ICs (32) and (34). 
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Another representative example of a transmission plan employed herein 
is transmitter (57), under control of IC (38), having an allocation of transmission 
media resource (61) for reception by receiver (54). IC (36) has transmitter (52) 
and transmission media resource (53) allocated for reception by receiver (50) at 
5 IC (38). This transmission plan may represent an asymmetric transmission, Le., 
the outbound channel from IC (38), represented at transmitter (57), has more 
media resources allocated which may indicate a higher bandwidth or higher data 
rate for reception by IC (36) through receiver (54) than the outbound channel 
from IC (36) through transmitter (52) through transmission media resource (53) 

10 for reception by receiver (50) to IC (38). Other representative permutations of 
the transmission plans employed herein are shown in Fig. 19 through the 
mapping transmission plan (43). 

Fig. 20 demonstrates the timing of how a representative transmission 
plan may be implemented by the management component. The transmission 

15 plan implementation begins with management component (100) having a 
predetermined command (102) to send to the network at a predetermined 
command time (110). Command(s) (102) is sent to IC (104) that must change 
transmission resource allocation at the implementation time. This command is 
stored in IC (104) and the time to implement the command is decoded by IC 

20 (104). IC (104) then sends a command acknowledgment (118) back to a 
management component (100). At this juncture, command (102) is loaded and 
awaits deployment at MC (100) at the predetermined command time (110). 
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Command (102) is resent (122) if acknowledgment of receipt of command (118) 
is not received before a predetermined time. 

It is understood that MC (100) may have a list of every IC (104) in the 
network that must change. This list may include the TCP/IP address for each IC 
5 (104) so MC (110) may send a UDP/IP message with a command (102) encoded 
therein. An acknowledgment deadline (134) is included that may be seconds 
before the implementation time for the new transmission plan. The 
acknowledgment deadline (134) may be the last time at which MC (106) can 
abort an implementation if each IC (104) does not acknowledge the commands. 
10 It is understood that IC (104) may use a coordinated implementation to 

assure that no IC (104) is stranded when the transmission plan is implemented. 
During the abort sequence, which occurs if IC (104) has not acknowledged 
command (102) at step (118), MC (106) sends an abort message (126) to IC 
(108) that were sent command (102). IC (108) may send an abort 
15 acknowledgment (128). Abort command (126) is resent at step (130) if it is not 
acknowledged. The implementation time (136) defines a time at which the 
transmission plan is executed by IC (104). It is understood that at that point, all 
necessary ICs (104) have acknowledged command (118) and are counting down 
in a synchronized fashion to the predetermined implementation time (136). It is 
20 understood that the command acknowledged may include an indication of the 
time at which an IC (104) received command (102) to verify that the 
implementation time (136) is synchronized among each IC (104). Once all 
commands have been acknowledged and the network is ready to implement the 
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plan, at implementation time (136), the ICs (104) implement the command(s) 
received from MC (100) at implementation time (136). 

At this point, a new transmission plan, as depicted in Fig. 19, may be 
implemented by the network. The communication path between MC (30) and 
5 ICs (32, 34, 36, 38, 40) is independent of the transmission media resources. As 
depicted in Fig. 19, a transmission path (31) is generally over a TCP/IP network 
(e.g., the Internet), as widely known in use today. However, it is within the 
scope of the present invention to define a guard or maintenance channel which 
may be a point-to-multi-point transmission scheme from MC (30) to and from 

10 ICs (32, 34, 36, 38, 40) wherein an IC co-located with MC (30) assures that a 
network connection is present between ICs (32, 34, 36, 38, 40) and a MC 
allocated transmitter, such as transmitter (44). In such a case, each IC (32, 34, 
36, 38, 40) ready to implement the new transmission plan may have a receiver 
dedicated to monitor transmitter (44) to receive abort command (126) if each IC 

15 (32, 34, 36, 38, 40) does not acknowledge. This assures a fail safe or guard 
channel back-up plan to abort implementation of a new transmission plan if one 
or more IC (32, 34, 36, 38, 40) loses communication with the management 
component. 

Commands may enter the IC (150) from a plurality of sources, one of 
20 which may be directly from the MC. Node (158) may be a UNIX daemon or a 
Windows NT™ service which monitors a TCP/IP address. Thus, commands 
from MC (156) may enter IC (150) through a port (204). Upon entering IC 
(150), network commands may be mapped at step (158) in conjunction with 
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configuration database information to output specific commands (178) to the 
network equipment. These commands may be put into a command queues (168, 
180, 184) which is then directed through a scheduler process 162, 170 and 186. 
For example, scheduled command implementation processes (162, 170, 186) 
5 may output commands to the appropriate receiver, transmitter or network device 
through a serial port (164, 166, 172, 174) or a parallel port (188, 190). 
Command queues (168, 180, 184) may be a polled or interrupt driven queue. 
That is, the schedule command implementation process (164) may periodically 
poll queues (168, 180, 184) to determine whether a command is present, and if 
10 so, pass the command on to the appropriate network device interfaced (e.g., 
serial device driver (164, 166)) or the command key may be a period. 

The command queue may alternatively be interrupt driven. That is, 
when a command enters queue (168, 180, 184), for example, command queue 
(168) may send an interrupt to the command implementation process for the 
15 command implementation process to service the command and then pass it to 
the appropriate network device at the appropriate serial port. It is understood 
that this process may be used for implementation processes (170, 186) as well. 

Command implementation processes (168, 170, 186) may be 
synchronized to network time (202) to execute commands at the appropriate 
20 time. That is, implementation of transmission plans may be synchronized with 
network time (202) to assure that all network devices reconfigure themselves 
simultaneously or near simultaneously. Implementation processes (168, 170, 
186) may also have data from configuration database (152) to configure 
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implementation process (168, 170, 186) for the particular end-user network 
device. This provides flexibility in implementation process (168, 170, 186). 
That is, the implementation may be written as a modular software program 
which may be modified by configuration database data (160) as implementation 
5 process (168, 170, 186) executes. Further to this concept is that MC (156) may 
address configuration database (152) via link (204) to change configuration 
database (152) to redefine the end-user equipment. This allows the MC (156) to 
manage the end-user equipment remotely from the user location at the IC site. 
IC (150) may communicate through module (158) via link (182) to send 

10 acknowledgments (200) back to the MC (156). Command acknowledgments 
(118) shown in Fig. 20 and order acknowledgments may also be used. Figs. 21- 
28 illustrate a step that may be used to confirm receipt of commands or to 
confirm receipt of an abort command. 

It is understood that there are at least two ways in which to map MC 

15 commands or at least two ways in which to map MC commands to the end-user 
device or to a particular port on a IC. First, a TCP/IP address is provided for the 
IC in command (204) and then, within the UDP command, is a sub-address that 
may be decoded at (158) addressed to a particular end-user device. 

Fig. 22 shows a graphical block diagram of an audit control process by 

20 which the present invention may collect data from network equipment. 
Equipment controller (150) may have a configuration database (152) which 
controls the configurations of the IC in relation to the end-user network 
equipment. An audit request (252) may be received from the MC via port (254). 
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Port (254) may be a user data packet via a TCP/IP network to a particular 
predetermined address at (256). At (256), an auto request command may be 
decoded to map an equipment name to hardware identification from those stored 
in configuration database (152). The process at (256) may also be used to map 
5 equipment attributes to data controls (290). These parameters may be passed to 
the reformat command process at (280) which is used to provide a formatted 
audit response (282) to the MC. 

In one embodiment of the present invention, the MC may establish an 
asynchronous data collection process (262, 264, 266) for the network equipment 
10 at a respective data port (268, 270, 272, 274, 276, 278) for the network 
equipment. Asynchronous data collection process (262, 264 266) may be 
interrupt or poll driven. 

In the interrupt driven embodiment of asynchronous data collection 
process (262, 264, 266), the end-user device may send out an unsolicited 

15 command via the respective device {e.g., device 268), to asynchronous data 
collection process (262, 264, 266). The interrupt then invokes the program to 
service the data condition (or possibly an alarm) from the network equipment. 
Asynchronous data collection process (262, 264, 266) then moves the data to the 
data control store block (258) where the alarm or data condition may be stored 

20 in the IC. It is understood that the data control store block (258) may be a hard 
drive or other long term storage means available at the BIC. In a preferred 
embodiment, the data control store is a non-volatile data storage media and the 
asynchronous data collection process is a modular program because it is 
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modified from data from configuration database (260) for the particular network 
device. This provides a flexible programming methodology for the 
asynchronous data collection process employed in the present invention. 

In the polled embodiment of asynchronous data collection process (262, 
5 264, 266), asynchronous data collection process (262), for example, may 
periodically pole the end-user network device attached to, for example, port 
(268), to receive data or alarm conditions from the end-user device. The polling 
rate may be a parameter from the configuration database received via link (260). 
In sum, an audit request may be received via port (254) and decoded at 
10 (256) to output data from the data control store program (292). Data output 
from the data control store may be formatted at (280) from parameters past 
(290) from the audit request. This can provide an auto response (294) back to 
the BMC (282) in the appropriate and predetermined format. 

Fig. 23 shows a logic flow representation of a network audit from a MC 
15 (302). In Fig. 23, the MC (302) may establish an auto time for a network 
element, a transmitter or receiver (300). At the appropriate time, MC (302) may 
send out an audit request (306). It is understood that audit request (306) is 
directed to the network element and the particular IC controlling that element 
(308). The IC may then query the network element and send an audit reply 
20 (312) to the MC (310). Audit reply (312) is shown in time synchronization 
(3 1 6) after audit request (306). 

Initialization or configuration files may be used to implement the 
invention. Exemplary initialization files are shown in Appendices A-H. For 
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example, a "command.ini" file (shown in Appendix A) may be used to provide 
user interface command definitions for all network management system 
equipment supported. The "command.ini" file specifies the menus associated 
with each control used on a user display. 
5 A "monitor.ini" file (shown in Appendix B) may be used to specify 

automatic monitoring functions performed by an equipment controller. The 
"monitor.ini» file may act as the network management system data connection 
interface definition file. 

An "equipctl.ini" file is shown in Appendix C. The "equipctl.ini" file 
10 may be used as the network management system controller initialization file. 
That is, the "equipctl.ini" file specifies some global parameters for the 
equipment controller application. It may also specify the location of other 
configuration files if such files are not stored in a default or pre-determined 
location. 

15 Appendix D shows an exemplary "evenUni" file. The "event.ini" file 

may provide descriptions of network management system events. For example, 
the "evenUni" file may specify textual responses (to user commands) displayed 
on a user interface and the asynchronous messages sent to either an event logger 
or other device. 

20 A "porUni" file (shown in Appendix E) may be used as the network 

management system external connection definition file. The "portini" file may 
specify particular serial and parallel ports used by the equipment controller 
application. 
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Appendix F shows an example of a "serial.ini" file. The "serial.ini" file 
may be used as the network management system serial command description 
file. This file may specify the command and response strings used to 
communicate with the manage equipment over a serial interface. 
5 An example of a network management system user interface definition 

file ("panel.ini" file) is shown in Appendix G. The "panel.ini" file may be an 
the overall specification for the display controller presentation. This file ties 
together the display controls with specific input/output ports and describes the 
total graphic user interface for an equipment controller site. 

10 Appendix H shows an exemplary "template.ini" file. The "template.ini" 

file may be used as the network management system display template 
description file. This file specifies the graphic qualities of the controls used in 
the display controller presentation. Graphic qualities may include the position 
of the graphic control on a display, the type of display object, the name of any 

15 required bitmap graphic file, and a reference to any menu associated with the 
control. 

The hardware identification field (1510) may contain information that 
identifies a specific transmitter or receiver at a site. The hardware identification 
field may have the format: 
20 HWID=<Class> :<Name> 

where 

<Class> is the type of hardware and 
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<Name> is the name assigned to a specific piece of hardware in the IC 
configuration. 

The type of hardware may be one of the following classes: 

□ Transmitter (TX) 
5 □ Receiver (RX) 

□ Upconverter (UC) 

□ Downconverter (DC) 

The <Class> portion of the hardware identification field may be one of the 
10 mnemonics shown in parentheses. Information fields (1524) and header fields 
(1528) may share some similarities. Each type of field is terminated with an 
ASCn linefeed (LF) character (1512, 1522). The primary difference between 
header fields (1528) and information fields (1524) is that the same header fields 
are found in all system messages while different messages can have different 
15 information fields. 

Because of the size of information fields (1524), the format of an 
information field is more complex than the format of a header field. 
Information fields may match the format: 

<mnemonic>=<value> 

20 where 

<mnemonic> is a mnemonic representing the field type and 

<value> is a string representation of the field value. 
Both the mnemonic and the value of an information field may consist of 
printable ASCII characters. However, the ASCII character '=' is used to 
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separate the mnemonic and value portions of an information field. Therefore, 
cannot be present is either the mnemonic or value strings. 

A transmission control order (TCO) is sent from management 
component to an IC to request parameter changes for a transmitter or receiver 
5 controlled by the IC. 

A TCO may have has the following information fields: 

□ Execution time 

□ Model parameters 

10 The execution time field specifies the time at which the TCO must be 

implemented. The TCO for each side of a communication link (transmitter and 
receiver) may have the same execution time to minimize the time the carrier is 
down during the change. Execution times may be given in UTC. The execution 
time field may have the format: 

15 ET=<YYYY><MM><DD><hh><mm> 
where 

<YYYY> is the four-digit year number (0000 to 9999), 
<MM> is the two-digit month number (January is "01", etc.), 
<DD> is the two-digit day of the month (01 to 3 1), 
20 <hh> is the two-digit hour of the day (00 to 23), and 

<mm> is the two-digit minute of the hour (00 to 59). 

All of the fields in a TCO after the execution time are model parameters. 
These fields are the parameter values for the transmitter or receiver specified by 
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the hardware identification field of a TCO. Model parameters are specified as a 
parameter/value pair. The format of a model parameter in a BMF message is: 
<mnemonic>=<value> 

where 

5 <mnemonio is the mnemonic for a model parameter and 

<value> is a string representation of the parameter value. 

An abort order (ABRT) may be sent to an IC to cancel any pending 
TCO for the specified hardware. An ABRT does not require any information 
10 fields. 

An acknowledgment (ACK) informs the management component that 
the IC received the TCO or ABRT. An ACK is the response message for a TCO 
or ABRT. When an IC receives a TCO or ABRT, it must send an 
acknowledgment to the management component. If the IC detects any problems 
15 with the TCO (configured hardware does not support a model parameter, 
hardware ID invalid, etc.) then the ACK will describe the problems. An ACK 
for an ABRT does not require this problem description. An ACK may have the 
following information fields: 

□ Execution time (same as in TCO) 
20 □ Model parameters (only if an error condition exists) 

An ACK may have the same information fields as the TCO that is being 
acknowledged. However, model parameter fields are only present if the IC 
cannot fulfill that model parameter. For example, if the TCO contained 



an 
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invalid receiver bit rate but a valid receiver frequency then the ACK would 
include an information field for the RXR model parameter but not for the RXF 
model parameter. 

An audit request (AREQ) is sent periodically by the MC for each 
5 transmitter and receiver in a satellite network. Each AREQ is sent to the BMF 
IC responsible for managing the specified transmitter or receiver. An AREQ 
does not require any information fields. 

An audit response (ARSP) is sent by an IC in response to an AREQ 
from the MC. An ARSP is the response message for an AREQ. An ARSP has 
10 the following information fields: 

a Execution time (time ARSP generated) 
□ Model parameters (actual settings) 

The format of an ARSP may be almost identical to the format of a TCO: ' 
15 the message contains an information field for all of the model parameters 
pertaining to the specified piece of hardware. However, the values of the model 
parameters may be the actual settings of the hardware, not the desired settings. 

One purpose of the ARSP is to determine the state of the hardware in the 
network. A secondary purpose is to check for manually instituted changes to the 
20 configuration of the network hardware. For example, an operator at a remote 
site might manually change the receiver frequency using the front panel of the 
equipment. The management component periodically requests the current state 
of all managed equipment to check for parameter modifications not initiated by 
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the management. The execution time for an audit response is the time at which 
the ARSP is generated. 

An ARSP may contain the model parameters for the type of equipment 
specified by the hardware identification. When the value for a model parameter 
5 is not available, the value portion of the field may be "UNKNOWN." For 
example, if the scrambling state of a transmitter cannot be determined by an IC, 
- the field "SCR=UNKNOWN" may appear in the audit response. 

The IC (IC) may read its configuration files at startup and construct 
memory resident database tables and data 'objects' to facilitate rapid access to 
10 the configuration information stored in those files. Among the data read from 
the configuration files are the records that describe the equipment that the 
Management Console (MC) application will attempt to control by its commands 
to the Equipment Controller. The MC may communicate with the Equipment 
Controller in message with a format similar to: 

15 

Equip=EquipmentClass:EquipmentUnitName 
Attribute l=Valuel 

Attribute2=Value2 

20 where 'EquipmentClass' and 'EquipmentName' are character string values that 
occur in the IC configuration files as identifying a piece of modeled equipment. 
The values of 'Attribute' and 'Value' are also represented as character strings and 
hence the entire dialog between the MC and IC is through text based messages. 



5DOCID: <WO 993B274A1 JA> 



SUBSTITUTE SHEET (RULE 26) 



WO 99/38274 . 45 . PCT/US99/0I31 7 



The IC configuration files identify one or more pieces of modeled 
equipment and a set of attributes that the modeled equipment can support. For 
example, the following section of an 'equipctl.ini' file describes an equipment 
element known as 'TRANSMITTERrOutbound'. The modeled attributes are 
5 identified by the 'EquipModemAttrs' entry and list the values TXF TXR MODT 
MODR ENCT ENCR DENC SCR PWR CXR as the legitimate attributes of the 
unit known as 'TRANSMITTER: Outbound'. 



[Outbound] 
10 EquipName=Outbound 

EquipClass=TRANSMITTER 

EquipModelAttrs=ALL TXF TXR MODT MODR ENCT ENCR DENC SCR 
PWR CXR 

EquipAttrSetCmds="" EFDataTxfSetCmd EFDataTxrSetCmd 
15 EFDataModtSetCmd 

EFDataModrSetCmd EFDataEnctSetCmd EFDataTxrSetCmd 
EFDataDencSetCmd EFDataScrSetCmd EFDataPwrSetCmd 
EFDataCarrierSetCmd 
EquipAttrSetCmdParms="TXF TXR ENCT PWR" "TXF" "ENCR TXR" 
20 "MODT" "MODR" "ENCT" "ENCR TXR" "DENC" "SCR" "PWR" 

"CXR" 

EquipAttrSetCmdPorts=Serial5 
EquipAttrSetCmdAddrs=" 1 " 
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EquipAttrMonConns="" EFDataTxfMon EFDataTxrMon EFDataModtMon 

EFDataModrMon EFDataEnctMon EFDataEncrMon EFDataDencMon 
EFDataScrMon EFDataPwrMon EFDataCarrierMon 
EquipAttrMonConnPorts=Serial5 
5 EqnipAttrMonConnAddrs=" 1 " 

AssociatedEquipment=RECEIVER:Demodl 



This configuration entry may also associate other configuration entries 
with the equipment attributes that permit the equipment controller to set 
10 (modify) and get (recover) the attribute values from an actual piece of serially 
attached equipment. The entries in the list of •EquipAttrSetCmds 1 refer to 
entries in the 'seriaLini' file that describe the actual command to be sent. The 
entries in the 'EquipAttrSetCmdPorts 1 and 'EquipAttrSetCmdAddrs' describe 
which serial port the attached equipment is connected to and the address of the 
15 attached equipment (in the case that multiple pieces of equipment are attached 
via the same serial port). Similarly, the 'EquipAttrMonConns 1 entry refer to 
configuration entries in the •monitor.ini 1 file that describe the mechanism by 
which the attribute is recovered from the attached equipment and the 
•EquipAttrMonConnPorts' and 'EquipAttrMonConnAddrs' describe the serial 
20 ports and addresses used for data recovery. 

Hence the IC is in not actually aware of the semantics of the data values 
it is 'setting 1 or 'getting' and the mapping between the equipment and equipment 
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attributes that the MC believes it is controlling is completely defined by the 
equipment controller configuration files and not equipment controller software. 

The MC and IC communicate via the text format generally described 
above. All communication is initiated by the MC. Three request packets are 
5 currently defined: 1) a request to modify the attributes of a particular piece of 
equipment at a particular time in the future, 2) a request to cancel the request to 
modify the attributes of a particular piece of equipment, and 3) a request to 
return the current values of the attributes of a particular piece of equipment. 
Each request is normally responded to with a complementary message. In some 
10 cases, however, no response message purposely generated in order to 
communicate a negative response. 

The request to modify the attributes of a particular piece of equipment is 
known as a Transmission Change Order (TCO). The format of a TCO is as 
follows: 

15 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 
Time=YYYYMMDDHHMM 
Attributel=Valuel 
20 Attribute2=Value2 

When the IC receives a TCO it validates the request. The request validation 
includes confirming that the requested change time has not already past and that 
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the IC configuration supports the requested modifications. The IC may refer to 
its memory resident database of configuration data to validate request. First, the 
IC may insure that the requested equipment is identified in the configuration. It 
then may insure, by tracing the attributes named in the request through the 
5 configuration to the commands that must be issued to insure that sufficient 
configuration information is present to form the required commands. Finally it 
may check to see if the equipment is currently responding to commands. 

If an error is detected such that the request cannot be supported by the 
configuration, a response may be returned to the MC identifying the offending 
10 request data. For example, if a request contained an equipment identification 
that did not exactly match an entry in the 'equipctl.ini' file or if an attribute name 
did not exactly match one of the legitimate attributes named in the 'equipctl.ini' 
file, a response would be sent indicating why the TCO was invalid and 
implicitly indicating that the request would not be implemented. Further, if a 
15 legitimate attribute is named, but the equipment controller finds that either no 
serial command is referenced or that the referenced serial command is not 
configured, the IC may also send a similar response indicating why the request 
cannot be implemented. Validation of the parameter values may also be 
accomplished in a similar technique. 
20 If the request is otherwise correct, but the equipment is currently not 

responding to serial commands, no response is purposely generated, which may 
indicate that no problem was detected in the request but that the since no 
acknowledgment was sent, the request will not be implemented at the specified 
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time. Otherwise, an acknowledgment is returned to the MC indicating that 
unless otherwise instructed, the IC will perform the requested configuration 
change at the requested time. The request to cancel the modification of the 
attributes of a particular piece of equipment is known as a Abort Message 
5 (ABRT). The format of an ABRT is as follows: 

ABRT 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 

10 

The IC may remove the outstanding command set to be issued to the 
specified equipment if any command is queued and may send an 
acknowledgment to the MC indicating it has done so. If, at the time of receipt, 
no command is outstanding, the IC may respond with a message indicating that 
15 no command was found. The request to recover the current values of the 
attributes of a particular piece of equipment is known as an Audit Message 
(AUDIT). The format of an AUDIT is as follows: 

AUDIT 

20 MessageSequenceNumber 

Equip=EquipmentClass:EquipmentUnitName 
AttributeName (optional) 
AttributeName (optional) 
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The MC may request the current values of the equipment attributes by 
sending an AUDIT message to the IC. The message may contain specific 
attribute names or, in the absence of any attribute names, all attributes 
associated with the equipment are returned. Should the equipment or attributes 
5 identified not be defined in the IC configuration, the IC will send a message 
similar to the negative acknowledgment to a TCO indicating what particular 
field of the request message was found in error. If the AUDIT request message 
is found to be supported by the current IC configuration, the IC may will use the 
configuration entries identified by the 'equipctl.ini 1 file to recover the current 
10 values and will form a response message similar to the TCO message and send 
it to the MC. The response message format is as follows: 



AUDIT 

MessageSequenceNumber 

1 5 Equip=EquipmentClass:EquipmentUnitName 
Time=YYYYMMDDHHMM 
Attribute l=Valuel 
Attribute2=Value2 



20 The Implementation component (IC) reads its configuration files at 

startup and constructs memory resident database tables and data 'objects' to 
facilitate rapid access to the configuration information stored in those files. 
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Among the data read from the configuration files are the records that 
describe the equipment that the Management Console (MC) application will 
attempt to control by its commands to the Equipment Controller. The MC will 
communicate with the Equipment Controller in message with a format similar 
5 to: 

Equip=EquipmentClass:EquipmentUnitName 

Attributel=Valuel 

Attribute2=Value2 

10 

where ! EquipmentClass' and f EquipmentName ! are character string values that 
occur in the IC configuration files as identifying a piece of modeled equipment. 
The values of 'Attribute 1 and 'Value 1 are also represented as character strings and 
hence the entire dialog between the MC and IC is through text based messages. 

15 The IC configuration files identify one or more pieces of modeled 

equipment and a set of attributes that the modeled equipment can support. For 
example, the following section of an 'equipctl.ini 1 file describes an equipment 
element known as TRANSMITTER:Outbound. t The modeled attributes are 
identified by the 'EquipModemAttrs' entry and list the values TXF TXR MODT 

20 MODR ENCT ENCR DENC SCR P WR CXR as the legitimate attributes of the 
unit known as TRANSMITTER:Outbound.' 
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[Outbound] 

EquipName=Outbound 
EquipClass=TRANSMITTER 

EquipModelAttrs=ALL TXF TXR MODT MODR ENCT ENCR DENC SCR 
5 PWRCXR 

EquipAttrSetCmds= ,,n EFDataTxfSetCmd EFDataTxrSetCmd 
EFDataModtSetCmd 

EFDataModrSetCmd EFDataEnctSetCmd EFDataTxrSetCmd 
EFDataDencSetCmd EFDataScrSetCmd EFDataPwrSetCmd 
10 EFDataCarrierSetCmd 

EquipAttrSetCmdParms="TXF TXR ENCT PWR" "TXF" "ENCR TXR" 
"MODT" "MODR" "ENCT" "ENCR TXR" "DENC" "SCR" "PWR" 
"CXR" 

EquipAttrSetCmdPorts=Serial5 
15 EquipAttrSetCmdAddrs="l" 

EquipAttrMonConns="" EFDataTxfMon EFDataTxrMon EFDataModtMon 

EFDataModrMon EFDataEnctMon EFDataEncrMon EFDataDencMon 
EFDataScrMon EFDataPwrMon EFDataCarrierMon 
EquipAttrMonConnPorts=Serial5 
20 EquipAttrMonConnAddrs="l" 

AssociatedEquipment=RECEIVER:Demod 1 
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This configuration entry also associates other configuration entries with 
the equipment attributes that permit the equipment controller to set (modify) and 
get (recover) the attribute values from an actual piece of serially attached 
equipment. The entries in the list of 'EquipAttrSetCmds' refer to entries in the 
5 'serial-ini* file that describe the actual command to be sent The entries in the 
'EquipAttrSetCmdPorts' and 'EquipAttrSetCmdAddrs 1 describe which serial port 
the attached equipment is connected to and the address of the attached 
equipment (in the case that multiple pieces of equipment are attached via the 
same serial port). Similarly, the 'EquipAttrMonConns' entry refer to 

10 configuration entries in the 'monitor.inf file that describe the mechanism by 
which the attribute is recovered from the attached equipment and the 
'EquipAttrMonConnPorts' and 'EquipAttrMonConnAddrs* describe the serial < 
ports and addresses used for data recovery. 

Hence the IC is in not actually aware of the semantics of the data values 

15 it is letting 1 or 'getting' and the mapping between the equipment and equipment 
attributes that the MC believes it is controlling is completely defined by the 
equipment controller configuration files and not equipment controller software. 

The MC and IC communicate via the text format generally described 
above. All communication is initiated by the MC. Three request packets are 

20 currently defined: 1) a request to modify the attributes of a particular piece of 
equipment at a particular time in the future, 2) a request to cancel the request to 
modify the attributes of a particular piece of equipment, and 3) a request to 
return the current values of the attributes of a particular piece of equipment. 
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Each request is normally responded to with a complementary message. In some 
cases, however, no response message purposely generated in order to 
communicate a negative response. 

The request to modify the attributes of a particular piece of equipment is 
5 known as a Transmission Change Order (TCO). The format of a TCO is as 
follows: 

TCO 

MessageSequenceNumber 

1 0 Equip=EquipmentClass:EquipmentUnitName 
Time=YYYYMMDDHHMM 
Attribute l=Valuel 
Attribute2=Value2 

15 When the IC receives a TCO it validates the request. The request 

validation includes confirming that the requested change time has not already 
past and that the IC configuration supports the requested modifications. The IC 
refers to its memory resident database of configuration data to validate request. 
First the IC insures that the requested equipment is identified in the 

20 configuration. It then insures, by tracing the attributes named in the request 
through the configuration to the commands that must be issued to insure that 
sufficient configuration information is present to form the required commands. 
Finally it checks to see if the equipment is currently responding to commands. 
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If an error is detected such that the request cannot be supported by the 
configuration, a response is returned to the MC identifying the offending request 
data. For example, if a request contained an equipment identification that did 
not exactly match an entry in the 'equipctl.inT file or if an attribute name did not 
5 exactly match one of the legitimate attributes named in the 'equipctl.ini 1 file, a 
response would be sent indicating why the TCO was invalid and implicitly 
indicating that the request would not be implemented. Further, if a legitimate 
attribute is named, but the equipment controller finds that either no serial 
command is referenced or that the referenced serial command is not configured, 
10 the IC will also send a similar response indicating why the request cannot be 
implemented. Validation of the parameter values may also be accomplished in a 
similar technique. 

If the request is otherwise correct, but the equipment is currently not 
responding to serial commands, no response is purposely generated, indicating 
15 that no problem was detected in the request but that the since no 
acknowledgment was sent, the request will not be implemented at the specified 
time. 

Else an acknowledgment is returned to the MC indicating that unless 
otherwise instructed, the IC will perform the requested configuration change at 
20 the requested time . 

The request to cancel the modification of the attributes of a particular 
piece of equipment is known as a Abort Message (ABRT). The format of an 
ABRT is as follows: 
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ABRT 

MessageSequenceNumber 
Equip=EquipmentClass:EquipmentUnitName 



5 The IC will remove the outstanding command set to be issued to the specified 
equipment if any command is queued and will send an acknowledgment to the 
MC indicating it has done so. If, at the time of receipt, no command is 
outstanding, the IC will respond with a message indicating that no command 
was found. 

10 Figure 13 depicts a flow chart of a transmission plan execution. 

Initially, the system may have an unscheduled transmission (1302). The 
transmission plan may be assigned an execution time (1304). The transmission 
plan may be propagated to the network to place the plan onto a pending status 
(1306). After all of the TCO's required to implement the transmission plan 

15 have acknowledged the command, the transmission plan is ready for execution 
(1308). At the transmission plan execution time (1310) the plan began the start 
sequence. After the MC confirms that all TCO's have been confirmed, e.g., so 
that the MC does not issue an abort command, the transmission plan goes active 
(1312). 

20 The system then begins normal operation on the new transmission plan 

and the system begins collecting data again on link usage (1316). Special 
transmission plans, e.g., transmission plans that are not recurring, are not re- 
scheduled (1318). 
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Figure 14 depicts a bandwidth allocation request. This control loop may 
execute at the MC. The system may receive a request for bandwidth 1402 from 
the Bandwidth administrator or an IC. The request may be an unscheduled 
network event 1404. The request for bandwidth is decoded and scheduled for 
5 execution 1406. The execution schedule may be for immediate execution or for 
a scheduled deployment. The appropriate TCO may be sent from the MC to the 
appropriate IC to propagate the transmission plan and to put the plan into the 
ready state 1408. The transmission plan then waits for its execution time. 
When the transmission plan execution time arrives (1410) the MC confirms that 

10 the TCO's were confirmed by the ICs. If the TCO's were confirmed, the plan 
goes active (1412) at the predetermined time, the system has thereby fulfilled 
(1414) the bandwidth request. 

The IC may implement a control loop similar to that shown and 
described above. The IC may confirm that a channel is available within the 

15 present transmission plan 1406 and immediately execute the new transmission 
pan 1408, 1410 and 1412. The IC may then notify the MC 1402 of the 
unscheduled 1404 transmission plan. The MC may then proceed as described 
above to propagate and deploy the new plan. 

Figure 5 depicts the inter-process communication between the MC 502 

20 and ICs (506) and 542. MC commands are sent via the UDP/IP link 504 from 
the control component 503 to the equipment control component 514. The 
equipment controller 514 then maps the generic network commands from the 
MC to specific commands (discussed above) for output (512) to the managed 
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equipment (510). The equipment controller (514) may lose the command event 
(524). The IC may also denote the command event on the local display 530. 

The system may receive alarm and other network messages that may 
effect the network management display 518 via the TCP/IP connection 516. 
5 Equipment controller 514 may connect to the display controller 518 when the 
equipment controller 514 receives an alarm condition from the network 
equipment (510,520) via command links (512, 522). The event logger (534) 
may receive network audits and network events from the IC 506 equipment 
controller (514) via UDP/IP link 532. As provided above, each of the 
1 0 communication processes on Figure 5 may be interpret or poll driven. 

The IC may also denote the command event on the local display 530. 
The system may receive alarm and other network messages that may 
effect the network management display 518 via the TCP/IP connection (516). 
Equipment controller (514) may connect to the display controller (518) when 
15 the equipment controller 514 receives an alarm condition from the network 
equipment (510,520) via command links (512, 522). The event logger (534) 
may receive network audits and network events from the IC 506 equipment 
controller (514) via UDP/IP link (532). As provided above, each of the 
communication processes on Figure 5 may be interrupt or poll driven. 
20 Other embodiments and uses of the invention will be apparent to those 

skilled in the art from consideration of the specification and practice of the 
invention disclosed herein. The specification and examples should be 
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considered exemplary only. The scope of the invention is only limited by the 
claims appended hereto. 
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Therefore we claim: 



1. A system for controlling a network of communication terminal 
comprising: 

5 a management component; 

an implementation component, said implementation component in 
communication with said management component to receive at least one 
transmission plan, said transmission plan containing a scheduled 
implementation time, said implementation component receiving said 
10 transmission plan, decoding an implementation time for said transmission plan 
and outputting command to network component at said implementation time to 
implement said transmission plan. 

2. A method for managing a communication network with an adaptive 
1 5 transmission plan comprising: 

analyzing network bandwidth allocation over a predetermined period of 

time; 

detennining a transmission plan to accommodate, at least in part, the 
results of said analysis of said network bandwidth allocation; 
20 deploying said transmission plan to a plurality of network component to 

implement said transmission plan; and 
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analyzing network bandwidth allocation short falls over a predetermined 
period of time to identify a transmission plan that accommodates bandwidth 
demands. 

5 3. A method for facilitating network management in a multiple vender 
network comprising: 

receiving a generic network command at an implement component; 
decoding said generic network command; 

translating said decoded generic network command to specific 
10 commands for a particular device through a text based file that contains text 
strings of specific device commands; and 

outputting said translated commands to said particular network device. 
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Figure 2 
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Figure 3 
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Figure 6; 
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Figure 9, 
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Figure 10 
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Figure 11 
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Figure 12. 
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Figure 13 
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Figure 14 
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Figure 15 
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Figure 16 
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Figure 17 
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